The foaf:Group
class represents a collection of individual agents (and may
itself play the role of a foaf:Agent
, ie. something that can perform actions).
This concept is intentionally quite broad, covering informal and
ad-hoc groups, long-lived communities, organizational groups within a workplace, etc. Some
such groups may have associated characteristics which could be captured in RDF (perhaps a
foaf:homepage
, foaf:name
, mailing list etc.).
While a foaf:Group
has the characteristics of a foaf:Agent
, it
is also associated with a number of other foaf:Agent
s (typically people) who
constitute the foaf:Group
. FOAF provides a mechanism, the
foaf:membershipClass
property, which relates a foaf:Group
to a
sub-class of the class foaf:Agent
who are members of the group. This is a
little complicated, but allows us to make group membership rules explicit.
The markup (shown below) for defining a group is both complex and powerful. It
allows group membership rules to match against any RDF-describable characteristics of the potential
group members. As FOAF and similar vocabularies become more expressive in their ability to
describe individuals, the foaf:Group
mechanism for categorising them into
groups also becomes more powerful.
While the formal description of membership criteria for a foaf:Group
may
be complex, the basic mechanism for saying that someone is in a foaf:Group
is
very simple. We simply use a foaf:member
property of the
foaf:Group
to indicate the agents that are members of the group. For example:
<foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:member> <foaf:Person> <foaf:name>Martin Poulter</foaf:name> <foaf:homepage rdf:resource="http://www.ilrt.bris.ac.uk/aboutus/staff/staffprofile/?search=plmlp"/> <foaf:workplaceHomepage rdf:resource="http://www.ilrt.bris.ac.uk/"/> </foaf:Person> </foaf:member> </foaf:Group>
Behind the scenes, further RDF statements can be used to express the rules for being a member of this group. End-users of FOAF need not pay attention to these details.
Here is an example. We define a foaf:Group
representing those people who
are ILRT staff members (ILRT is a department at the University of Bristol). The foaf:membershipClass
property connects the group (conceived of as a social
entity and agent in its own right) with the class definition for those people who
constitute it. In this case, the rule is that all group members are in the
ILRTStaffPerson class, which is in turn populated by all those things that are a
foaf:Person
and which have a foaf:workplaceHomepage
of
http://www.ilrt.bris.ac.uk/. This is typical: FOAF groups are created by
specifying a sub-class of foaf:Agent
(in fact usually this
will be a sub-class of foaf:Person
), and giving criteria
for which things fall in or out of the sub-class. For this, we use the
owl:onProperty
and owl:hasValue
properties,
indicating the property/value pairs which must be true of matching
agents.
<!-- here we see a FOAF group described. each foaf group may be associated with an OWL definition specifying the class of agents that constitute the group's membership --> <foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:membershipClass> <owl:Class rdf:about="http://ilrt.example.com/groups#ILRTStaffPerson"> <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/workplaceHomepage"/> <owl:hasValue rdf:resource="http://www.ilrt.bris.ac.uk/"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </foaf:membershipClass> </foaf:Group>
Note that while these example OWL rules for being in the eg:ILRTStaffPerson class are
based on a foaf:Person
having a particular
foaf:workplaceHomepage
, this places no obligations on the authors of actual
FOAF documents to include this information. If the information is included, then
generic OWL tools may infer that some person is an eg:ILRTStaffPerson. To go the extra
step and infer that some eg:ILRTStaffPerson is a foaf:member
of the group
whose foaf:name
is "ILRT staff", tools will need some knowledge of the way
FOAF deals with groups. In other words, generic OWL technology gets us most of the way,
but the full foaf:Group
machinery requires extra work for implimentors.
The current design names the relationship as pointing from the group, to the member. This is convenient when writing XML/RDF that encloses the members within markup that describes the group. Alternate representations of the same content are allowed in RDF, so you can write claims about the Person and the Group without having to nest either description inside the other. For (brief) example:
<foaf:Group> <foaf:member rdf:nodeID="martin"/> <!-- more about the group here --> </foaf:Group> <foaf:Person rdf:nodeID="martin"> <!-- more about martin here --> </foaf:Person>
There is a FOAF issue tracker associated with this FOAF term. A design goal is to make the most of W3C's OWL language for representing group-membership criteria, while also making it easy to leverage existing groups and datasets available online (eg. buddylists, mailing list membership lists etc). Feedback on the current design is solicited! Should we consider using SPARQL queries instead, for example?