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:Agents (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?