Class: foaf:Agent

Thefoaf:Agent class is the class of agents; things that do stuff. A well known sub-class isfoaf:Person, representing people. Other kinds of agents includefoaf:Organization andfoaf:Group.

Thefoaf:Agent class is useful in a few places in FOAF wherefoaf:Person would have been overly specific. For example, the IM chat ID properties such asjabberID are typically associated with people, but sometimes belong to software bots.

[back to top]

Class: foaf:Document

Thefoaf:Document class represents those things which are, broadly conceived, 'documents'.

Thefoaf:Image class is a sub-class offoaf:Document, since all images are documents.

We do not (currently) distinguish precisely between physical and electronic documents, or between copies of a work and the abstraction those copies embody. The relationship between documents and their byte-stream representation needs clarification (seefoaf:sha1 for related issues).

[back to top]

Class: foaf:Group

Thefoaf:Group class represents a collection of individual agents (and may itself play the role of afoaf: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 afoaf:homepage,foaf:name, mailing list etc.).

While afoaf:Group has the characteristics of afoaf:Agent, it is also associated with a number of otherfoaf:Agents (typically people) who constitute thefoaf:Group. FOAF provides a mechanism, thefoaf:membershipClass property, which relates afoaf:Group to a sub-class of the classfoaf: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, thefoaf:Group mechanism for categorising them into groups also becomes more powerful.

While the formal description of membership criteria for afoaf:Group maybe complex, the basic mechanism for saying that someone is in afoaf:Group isvery simple. We simply use afoaf:member property of thefoaf: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>Libby Miller</foaf:name>   <foaf:homepage rdf:resource="http://ilrt.org/people/libby/"/>   <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 afoaf:Group representing those people who are ILRT staff members. Thefoaf: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 afoaf:Person and which have afoaf:workplaceHomepage of http://www.ilrt.bris.ac.uk/. This is typical: FOAF groups are created by specifying a sub-class offoaf:Agent (in fact usually this will be a sub-class offoaf:Person), and giving criteria for which things fall in or out of the sub-class. For this, we use theowl:onProperty andowl: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 afoaf:Person having a particularfoaf:workplaceHomepage, this places no obligations on the authors of actual FOAF documents to include this information. If the informationis 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 afoaf:member of the group whosefoaf: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 fullfoaf:Group machinery requires extra work for implimentors.

The current design names the relationship as pointingfrom 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="libby"/> <!-- more about the group here --></foaf:Group><foaf:Person rdf:nodeID="libby">  <!-- more about libby here --></foaf:Person>

There is a FOAFissue tracker associated with this FOAF term. A design goal is to make the most of W3C'sOWL 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?

[back to top]

Class: foaf:Image

The classfoaf:Image is a sub-class offoaf:Document corresponding to those documents which are images.

Digital images (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.) are examples offoaf:Image.

[back to top]

Class: foaf:OnlineAccount

Afoaf:OnlineAccount represents the provision of some form of online service, by some party (indicated indirectly via afoaf:accountServiceHomepage) to somefoaf:Agent. Thefoaf:holdsAccount property of the agent is used to indicate accounts that are associated with the agent.

Seefoaf:OnlineChatAccount for an example. Other sub-classes includefoaf:OnlineEcommerceAccount andfoaf:OnlineGamingAccount.

[back to top]

Class: foaf:OnlineChatAccount

Afoaf:OnlineChatAccount is afoaf:OnlineAccount devoted to chat / instant messaging.

This is a generalization of the FOAF Chat ID properties,foaf:jabberID,foaf:aimChatID,foaf:msnChatID,foaf:icqChatID andfoaf:yahooChatID.

Unlike those simple properties,foaf:OnlineAccount and associated FOAF terms allows us to describe a great variety of online accounts, without having to anticipate them in the FOAF vocabulary.

For example, here is a description of an IRC chat account, specific to the Freenode IRC network:

<foaf:Person>  <foaf:name>Dan Brickley</foaf:name>  <foaf:holdsAccount>    <foaf:OnlineAccount>      <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/OnlineChatAccount"/>      <foaf:accountServiceHomepage rdf:resource="http://www.freenode.net/irc_servers.shtml"/>      <foaf:accountName>danbri</foaf:accountName>    </foaf:OnlineAccount>  </foaf:holdsAccount></foaf:Person>

Note that it may be impolite to carelessly reveal someone else's chat identifier (which might also serve as an indicate of email address) As with email, there are privacy and anti-SPAM considerations. FOAF does not currently provide a way to represent an obfuscated chat ID (ie. there is no parallel to thefoaf:mbox /foaf:mbox_sha1sum mapping).

In addition to the genericfoaf:OnlineAccount andfoaf:OnlineChatAccount mechanisms, FOAF also provides several convenience chat ID properties (foaf:jabberID,foaf:aimChatID,foaf:icqChatID,foaf:msnChatID,foaf:yahooChatID). These serve as as a shorthand for some common cases; their use may not always be appropriate.

We should specify some mappings between the abbreviated and full representations ofJabber,AIM,MSN,ICQ,Yahoo! andMSN chat accounts. This requires us to identify an appropriatefoaf:accountServiceHomepage for each. If we wanted to make thefoaf:OnlineAccount mechanism even more generic, we could invent a relationship that holds between afoaf:OnlineAccount instance and a convenience property. To continue the example above, we could describe howFreenode could define a property 'fn:freenodeChatID' corresponding to Freenode online accounts.

[back to top]

Class: foaf:OnlineEcommerceAccount

Afoaf:OnlineEcommerceAccount is afoaf:OnlineAccount devoted to buying and/or selling of goods, services etc. Examples includeAmazon,eBay,PayPal,thinkgeek, etc.

[back to top]

Class: foaf:OnlineGamingAccount

Afoaf:OnlineGamingAccount is afoaf:OnlineAccount devoted to online gaming.

Examples might includeEverQuest,Xbox live,Neverwinter Nights, etc., as well as older text-based systems (MOOs, MUDs and suchlike).

[back to top]

Class: foaf:Organization

Thefoaf:Organization class represents a kind offoaf:Agent corresponding to social instititutions such as companies, societies etc.

This is a more 'solid' class thanfoaf:Group, which allows for more ad-hoc collections of individuals. These terms, like the correspondingnatural language concepts, have some overlap, but different emphasis.

[back to top]

Class: foaf:Person

Thefoaf:Person class represents people. Something is afoaf:Person if it is a person. We don't nitpic about whether they're alive, dead, real, or imaginary. Thefoaf:Person class is a sub-class of thefoaf:Agent class, since all people are considered 'agents' in FOAF.

[back to top]

Class: foaf:PersonalProfileDocument

Thefoaf:PersonalProfileDocument class represents thosethings that are afoaf:Document, and that use RDF todescribe properties of the person who is thefoaf:makerof the document. There is just onefoaf:Person described inthe document, ie.the person whofoaf:made it and who will be itsfoaf:primaryTopic.

Thefoaf:PersonalProfileDocument class, and FOAF'sassociated conventions for describing it, captures an importantdeployment pattern for the FOAF vocabulary. FOAF is very often used inpublic RDF documents made available through the Web. There is acolloquial notion that these "FOAF files" are oftensomebody'sFOAF file. Throughfoaf:PersonalProfileDocument we providea machine-readable expression of this concept, providing a basis for FOAF documents to make claims about their maker and topic.

When describing afoaf:PersonalProfileDocument it istypical (and useful) to describe its associatedfoaf:Personusing thefoaf:maker property. Anything that is afoaf:Person and that is thefoaf:maker of somefoaf:Document will be thefoaf:primaryTopic ofthatfoaf:Document. Although this can be inferred, it ishelpful to include this information explicitly within thefoaf:PersonalProfileDocument.

For example, here is a fragment of a personal profile document whichdescribes its author explicitly:

<foaf:Person rdf:nodeID="p1"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="http://rdfweb.org/people/danbri/"/> <!-- etc... --></foaf:Person><foaf:PersonalProfileDocument rdf:about="">   <foaf:maker rdf:nodeID="p1"/>   <foaf:primaryTopic rdf:nodeID="p1"/></foaf:PersonalProfileDocument>

Note that afoaf:PersonalProfileDocument will have somerepresentation as RDF. Typically this will be in W3C's RDF/XML syntax,however we leave open the possibility for the use of other notations, orrepresentational conventions including automated transformations fromHTML (GRDDL spec forone such technique).

[back to top]

Class: foaf:Project

Thefoaf:Project class represents the class of things that are 'projects'. These may be formal or informal, collective or individual. It is often useful to indicate thefoaf:homepage of afoaf:Project.

Further work is needed to specify the connections between this class and the FOAF propertiesfoaf:currentProject andfoaf:pastProject.

[back to top]

Property: foaf:accountName

Thefoaf:accountName property of afoaf:OnlineAccount is a textual representation of the account name (unique ID) associated with that account.

[back to top]

Property: foaf:accountServiceHomepage

Thefoaf:accountServiceHomepage property indicates a relationship between afoaf:OnlineAccount and the homepage of the supporting service provider.

[back to top]

Property: foaf:aimChatID

Thefoaf:aimChatID property relates afoaf:Agent to a textual identifier ('screenname') assigned to them in the AOL Instant Messanger (AIM) system. See AOL'sAIM site for more details of AIM and AIM screennames. TheiChat tools fromApple also make use of AIM identifiers.

Seefoaf:OnlineChatAccount (andfoaf:OnlineAccount) for amore general (and verbose) mechanism for describing IM and chat accounts.

[back to top]

Property: foaf:based_near

Thefoaf:based_near relationship relates two "spatial things"(anything that canbe somewhere), the latter typicallydescribed using the geo:lat / geo:longgeo-positioning vocabulary(SeeGeoInfo in the W3C semwebwiki for details). This allows us to say describe the typical latitute and longitude of, say, a Person (people are spatial things - they can be places) without implying that a precise location has been given.

We do not say much about what 'near' means in this context; it is a'rough and ready' concept. For a more precise treatment, seeGeoOnion vocab designdiscussions, which are aiming to produce a more sophisticated vocabulary for such purposes.

FOAF files often make use of thecontact:nearestAirport property. Thisillustrates the distinction between FOAF documents (which may make claims usingany RDFvocabulary) and the core FOAF vocabulary defined by this specification. For further reading onthe use ofnearestAirport seeUsingContactNearestAirport in the FOAF wiki.

[back to top]

Property: foaf:birthday

Thefoaf:birthday property is a relationship between afoaf:Agent and a string representing the month and day in which they were born (Gregorian calendar).SeeBirthdayIssue for details of related properties that can be used to describe such things in more flexible ways.

[back to top]

Property: foaf:currentProject

Afoaf:currentProject relates afoaf:Personto afoaf:Document indicating some collaborative orindividual undertaking. This relationshipindicates that thefoaf:Person has some active role in theproject, such as development, coordination, or support.

When afoaf:Person is no longer involved with a project, orperhaps is inactive for some time, the relationship becomes afoaf:pastProject.

If thefoaf:Person has stopped working on a project because ithas been completed (successfully or otherwise),foaf:pastProject isapplicable. In general,foaf:currentProject is used to indicatesomeone's current efforts (and implied interests, concerns etc.), whilefoaf:pastProject describes what they've previously been doing.

Note that this property requires further work. There has been confusion about whether it points to a thing (eg. something you've made; a homepage for a project, ie. afoaf:Document or to instances of the classfoaf:Project, which might themselves have afoaf:homepage. In practice, it seems to have been used in a similar way tofoaf:interest, referencing homepages of ongoing projects.

[back to top]

Property: foaf:depiction

Thefoaf:depiction property is a relationship between a thing and anfoaf:Image that depicts it. As such it is an inverse of thefoaf:depicts relationship.

A common use offoaf:depiction (andfoaf:depicts) is to indicate the contents of a digital image, for example the people or objects represented in an online photo gallery.

Extensions to this basic idea include 'Co-Depiction' (social networks as evidenced in photos), as well as richer photo metadata through the mechanism of using SVG paths to indicate theregions of an image which depict some particular thing. See'Annotating Images With SVG' for tools and details.

The basic notion of 'depiction' could also be extended to deal with multimedia content (video clips, audio), or refined to deal with corner cases, such as pictures of pictures etc.

Thefoaf:depiction property is a super-property of the more specific propertyfoaf:img, which is used more sparingly. You stand in afoaf:depiction relation toanyfoaf:Image that depicts you, whereasfoaf:img is typically used to indicate a few images that are particularly representative.

[back to top]

Property: foaf:depicts

Thefoaf:depicts property is a relationship between afoaf:Image and something that the image depicts. As such it is an inverse of thefoaf:depiction relationship. Seefoaf:depiction for further notes.

[back to top]

Property: foaf:dnaChecksum

Thefoaf:dnaChecksum property is mostly a joke, but also a reminder that there will be lots of different identifying properties for people, some of which we might find disturbing.

[back to top]

Property: foaf:family_name

A number of naming constructs are under development to providenaming substructure; draft properties includefoaf:firstName,foaf:givenname, andfoaf:surname. These are not currently stable or consistent; see theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simplefoaf:name property.

[back to top]

Property: foaf:firstName

A number of naming constructs are under development to providenaming substructure; draft properties includefoaf:firstName,foaf:givenname, andfoaf:surname. These are not currently stable or consistent; see theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simplefoaf:name property.

[back to top]

Property: foaf:fundedBy

Thefoaf:fundedBy property relates something to something else that has provided funding for it.

This property is under-specified, experimental, and should be considered liable to change.

[back to top]

Property: foaf:geekcode

Thefoaf:geekcode property is used to represent a 'Geek Code' for somefoaf:Person.

See theCode of the Geeks specification for details of the code, which provides a somewhat frivolous and willfully obscure mechanism for characterising technical expertise, interests and habits. Thefoaf:geekcode property is not bound to any particular version of the code. The last published version of the code was v3.12 in March 1996.

As theGeek Code website notes, the code played a small (but amusing) part in the history of the Internet. Thefoaf:geekcode property exists in acknowledgement of this history. It'll never be 1996 again.

Note that the Geek Code is a densely packed collections of claims about the person it applies to; to express these claims explicitly in RDF/XML would be incredibly verbose. The syntax of the Geek Code allows for '<' and '>' characters, which have special meaning in RDF/XML. Consequently these should be carefully escaped in markup.

An example Geek Code:

GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G++++ e++ h r-- y++**

...would be written in FOAF RDF/XML as follows:

<foaf:geekcode> GED/J d-- s:++&gt;: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w--- O- M+ V-- PS++&gt;$ PE++&gt;$ Y++ PGP++ t- 5+++ X++ R+++&gt;$ tv+ b+ DI+++ D+++ G++++ e++ h r-- y++** </foaf:geekcode>

See also thegeek code entry ineverything2, which tells us thatthe geek code originated in 1993; it was inspired (according to the inventor) by previous "bear", "smurf" and "twink" style-and-sexual-preference codes from lesbian and gay newsgroups. There is also aGeek Code Decoder Page and a form-basedgenerator.

[back to top]

Property: foaf:gender

Thefoaf:gender property relates afoaf:Agent (typically afoaf:Person) to a string representing its gender. In most cases the value will be the string 'female' or 'male' (in lowercase without surrounding quotes or spaces). Like all FOAF properties, there is in general no requirement to usefoaf:gender in any particular document or description. Values other than 'male' and 'female' may be used, but are not enumerated here. Thefoaf:gender mechanism is not intended to capture the full variety of biological, social and sexual concepts associated with the word 'gender'.

Anything that has afoaf:gender property will be some kind offoaf:Agent. However there are kinds offoaf:Agent to which the concept of gender isn't applicable (eg. afoaf:Group). FOAF does not currently include a class corresponding directly to "the type of thing that has a gender".At any point in time, afoaf:Agent has at most one value forfoaf:gender. FOAF does not treatfoaf:gender as astatic property; the same individual may have different values for this property at different times.

Note that FOAF's notion of gender isn't defined biologically or anatomically - this would be tricky since we have a broad notion that applies to allfoaf:Agents (including robots - eg. Bender from Futurama is 'male'). As stressed above, FOAF's notion of gender doesn't attempt to encompass the full range of concepts associated with human gender, biology and sexuality. As such it is a (perhaps awkward) compromise between the clinical and the social/psychological. In general, a person will be the best authority on theirfoaf:gender. Feedback on this design is particularly welcome (via the FOAF mailing list,rdfweb-dev). We have tried to be respectful of diversity without attempting to catalogue or enumerate that diversity.

This may also be a good point for a periodic reminder: as with all FOAF properties, documents that use 'foaf:gender' will on occassion be innacurate, misleading or outright false. FOAF, like all open means of communication, supportslying. Application authors using FOAF data should always be cautious in their presentation of unverified information, but be particularly sensitive to issues and risks surrounding sex and gender (including privacy and personal safety concerns). Designers of FOAF-based user interfaces should be careful to allow users to omitfoaf:gender when describing themselves and others, and to allow at least for values other than 'male' and 'female' as options. Users of information conveyed via FOAF (as via information conveyed through mobile phone text messages, email, Internet chat, HTML pages etc.) should be skeptical of unverified information.

[back to top]

Property: foaf:givenname

A number of naming constructs are under development to providenaming substructure; draft properties includefoaf:firstName,foaf:givenname, andfoaf:surname. These are not currently stable or consistent; see theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simplefoaf:name property.

[back to top]

Property: foaf:holdsAccount

Thefoaf:holdsAccount property relates afoaf:Agent to anfoaf:OnlineAccount for which they are the sole account holder. Seefoaf:OnlineAccount for usage details.

[back to top]

Property: foaf:homepage

Thefoaf:homepage property relates something to a homepage about it.

Many kinds of things have homepages. FOAF allows a thing to have multiple homepages, but constrainsfoaf:homepage so that there can be only one thing that has any particular homepage.

A 'homepage' in this sense is a public Web document, typically but not necessarily available in HTML format. The page has as afoaf:topic the thing whose homepage it is. The homepage is usually controlled, edited or published by the thing whose homepage it is; as such one might look to a homepage for information on its owner from its owner. This works for people, companies, organisations etc.

Thefoaf:homepage property is a sub-property of the more generalfoaf:page property for relating a thing to a page about that thing. See alsofoaf:topic, the inverse of thefoaf:page property.

[back to top]

Property: foaf:icqChatID

Thefoaf:icqChatID property relates afoaf:Agent to a textual identifier assigned to them in the ICQ Chat system. See theicq chat site for more details of the 'icq' service. Their "What is ICQ?" document provides a basic overview, while their "About Us page notes that ICQ has been acquired by AOL. Despite the relationship with AOL, ICQ is at the time of writing maintained as a separate identity from the AIM brand (seefoaf:aimChatID).

Seefoaf:OnlineChatAccount (andfoaf:OnlineAccount) for amore general (and verbose) mechanism for describing IM and chat accounts.

[back to top]

Property: foaf:img

Thefoaf:img property relates afoaf:Person to afoaf:Image that represents them. Unlike its super-propertyfoaf:depiction, we only usefoaf:img when an image is particularly representative of some person. The analogy is with the image(s) that might appear on someone's homepage, rather than happen to appear somewhere in their photo album.

Unlike the more generalfoaf:depiction property (and its inverse,foaf:depicts), thefoaf:img property is only used with representations of people (ie. instances offoaf:Person). So you can't use it to find pictures of cats, dogs etc. The basic idea is to have a term whose use is more restricted thanfoaf:depiction so we can have a useful way of picking out a reasonable image to represent someone. FOAF definesfoaf:img as a sub-property offoaf:depiction, which means that the latter relationship is implied whenever two things are related by the former.

Note thatfoaf:img does not have any restrictions on the dimensions, colour depth, format etc of thefoaf:Image it references.

Terminology: note thatfoaf:img is a property (ie. relationship), and thatcode:Image is a similarly named class (ie. category, a type of thing). It might have been more helpful to callfoaf:img 'mugshot' or similar; instead it is named by analogy to the HTML IMG element.

[back to top]

Property: foaf:interest

Thefoaf:interest property represents an interest of afoaf:Agent, through indicating afoaf:Document whosefoaf:topic(s) broadly characterises that interest.

For example, we might claim that a person or group has an interest in RDF by saying theystand in afoaf:interest relationship to theRDF home page. Loosly, such RDF would be saying"this agent is interested in the topic of this page".

Uses offoaf:interest include a variety of filtering and resource discovery applications. It could be used, for example, to help find answers to questions such as "Find me members of this organisation with an interest in XML who have also contributed toCPAN)".

This approach to characterising interests is intended to compliment other mechanisms (such as the use of controlled vocabulary). It allows us to use a widely known set of unique identifiers (Web page URIs) with minimal pre-coordination. Since URIs have a controlled syntax, this makes data merging much easier than the use of free-text characterisations of interest.

Note that interest does not imply expertise, and that this FOAF term provides no support for characterising levels of interest: passing fads and lifelong quests are both examples of someone'sfoaf:interest. Describing interests in full is a complex undertaking;foaf:interest provides one basic component of FOAF's approach to these problems.

[back to top]

Property: foaf:isPrimaryTopicOf

Thefoaf:isPrimaryTopicOf property relates something to a document that is mainly about it.

Thefoaf:isPrimaryTopicOf property isinverse functional: forany document that is the value of this property, there is at most one thing in the worldthat is the primary topic of that document. This is useful, as it allows for data merging, as described in the documentation for its inverse,foaf:primaryTopic.

foaf:page is a super-property offoaf:isPrimaryTopicOf. The change of terminology between the two property names reflects the utility of 'primaryTopic' and its inverse when identifying things. Anything that has anisPrimaryTopicOf relation to some document X, also has afoaf:page relationship to it.

Note thatfoaf:homepage, is a sub-property of bothfoaf:page andfoaf:isPrimarySubjectOf. The awkwardly namedfoaf:isPrimarySubjectOf is less specific, and can be used with any document that is primarily about the thing of interest (ie. not just on homepages).

[back to top]

Property: foaf:jabberID

Thefoaf:jabberID property relates afoaf:Agent to a textual identifier assigned to them in theJabber messaging system. See theJabber site for more information about the Jabber protocols and tools.

Jabber, unlike several other online messaging systems, is based on an open, publically documented protocol specification, and has a variety of open source implementations. Jabber IDs can be assigned to a variety of kinds of thing, including software 'bots', chat rooms etc. For the purposes of FOAF, these are all considered to be kinds offoaf:Agent (ie. things thatdo stuff). The uses of Jabber go beyond simple IM chat applications. Thefoaf:jabberID property is provided as a basic hook to help support RDF description of Jabber users and services.

Seefoaf:OnlineChatAccount (andfoaf:OnlineAccount) for amore general (and verbose) mechanism for describing IM and chat accounts.

[back to top]

Property: foaf:knows

Thefoaf:knows property relates afoaf:Person to anotherfoaf:Person that he or she knows.

We take a broad view of 'knows', but do require some form of reciprocated interaction (ie. stalkers need not apply). Since social attitudes and conventions on this topic vary greatly between communities, counties and cultures, it is not appropriate for FOAF to be overly-specific here.

If someonefoaf:knows a person, it would be usual for the relation to be reciprocated. However this doesn't mean that there is any obligation for either party to publish FOAF describing this relationship. Afoaf:knows relationship does not imply friendship, endorsement, or that a face-to-face meeting has taken place: phone, fax, email, and smoke signals are all perfectly acceptable ways of communicating with people you know.

You probably know hundreds of people, yet might only list a few in your public FOAF file. That's OK. Or you might list them all. It is perfectly fine to have a FOAF file and not list anyone else in it at all. This illustrates the Semantic Web principle of partial description: RDF documents rarely describe the entire picture. There is always more to be said, more information living elsewhere in the Web (or in our heads...).

Sincefoaf:knows is vague by design, it may be suprising that it has uses. Typically these involve combining other RDF properties. For example, an application might look at properties of eachfoaf:weblog that wasfoaf:made by someone you "foaf:knows". Or check the newsfeed of the online photo archive for each of these people, to show you recent photos taken by people you know.

To provide additional levels of representation beyond mere 'knows', FOAF applications can do several things.

They can use more precise relationships thanfoaf:knows to relate people to people. The original FOAF design included two of these ('knowsWell','friend') which we removed because they were somewhatawkward to actually use, bringing an inappopriate air of precision to an intrinsically vague concept. Other extensions have been proposed, including Eric Vitiello'sRelationship module for FOAF.

In addition to using more specialised inter-personal relationship types (eg rel:acquaintanceOf etc) it is often just as good to use RDF descriptions of the states of affairs which imply particular kinds of relationship. So for example, two people who have the same value for theirfoaf:workplaceHomepage property are typically colleagues. We don't (currently) clutter FOAF up with these extra relationships, but the facts can be written in FOAF nevertheless. Similarly, if there exists afoaf:Document that has two people listed as itsfoaf:makers, then they are probably collaborators of some kind. Or if two people appear in 100s of digital photos together, there's a good chance they're friends and/or colleagues.

So FOAF is quite pluralistic in its approach to representing relationships between people. FOAF is built on top of a general purpose machine language for representing relationships (ie. RDF), so is quite capable of representing any kinds of relationship we care to add. The problems are generally social rather than technical; deciding on appropriate ways of describing these interconnections is a subtle art.

Perhaps the most important use offoaf:knows is, alongside therdfs:seeAlso property, to connect FOAF files together. Taken alone, a FOAF file is somewhat dull. But linked in with 1000s of other FOAF files it becomes more interesting, with each FOAF file saying a little more about people, places, documents, things... By mentioning other people (viafoaf:knows or other relationships), and by providing anrdfs:seeAlso link to their FOAF file, you can make it easy for FOAF indexing tools ('scutters') to find your FOAF and the FOAF of the people you've mentioned. And the FOAF of the people they mention, and so on. This makes it possible to build FOAF aggregators without the need for a centrally managed directory of FOAF files...

[back to top]

Property: foaf:logo

Thefoaf:logo property is used to indicate a graphical logo of some kind.It is probably underspecified...

[back to top]

Property: foaf:made

Thefoaf:made property relates afoaf:Agent to somethingfoaf:made by it. As such it is an inverse of thefoaf:maker property, which relates a thing to something that made it. Seefoaf:made for more details on the relationship between these FOAF terms and related Dublin Core vocabulary.

[back to top]

Property: foaf:maker

Thefoaf:maker property relates something to afoaf:Agent thatfoaf:made it. As such it is an inverse of thefoaf:made property.

Thefoaf:name (or otherrdfs:label) of thefoaf:maker of something can be described as thedc:creator of that thing.

For example, if the thing named by the URI http://rdfweb.org/people/danbri/ has afoaf:maker that is afoaf:Person whosefoaf:name is 'Dan Brickley', we can conclude that http://rdfweb.org/people/danbri/ has adc:creator of 'Dan Brickley'.

FOAF descriptions are encouraged to usedc:creator only for simple textual names, and to usefoaf:maker to indicate creators, rather than risk confusing creators with their names. This follows most Dublin Core usage. SeeUsingDublinCoreCreator for details.

[back to top]

Property: foaf:mbox

Thefoaf:mbox property is a relationship between the owner of a mailbox and a mailbox. These are typically identified using the mailto: URI scheme (seeRFC 2368).

Note that there are many mailboxes (eg. shared ones) which are not thefoaf:mbox of anyone. Furthermore, a person can have multiplefoaf:mbox properties.

In FOAF, we often seefoaf:mbox used as an indirect way of identifying its owner. This works even if the mailbox is itself out of service (eg. 10 years old), since the property is defined in terms of its primary owner, and doesn't require the mailbox to actually be being used for anything.

Many people are wary of sharing information about their mailbox addresses in public. To address such concerns whilst continuing the FOAF convention of indirectly identifying people by referring to widely known properties, FOAF also provides thefoaf:mbox_sha1sum mechanism, which is a relationship between a person and the value you get from passing a mailbox URI to the SHA1 mathematical function.

[back to top]

Property: foaf:mbox_sha1sum

Afoaf:mbox_sha1sum of afoaf:Person is a textual representation of the result of applying the SHA1 mathematical functional to a 'mailto:' identifier (URI) for an Internet mailbox that they stand in afoaf:mbox relationship to.

In other words, if you have a mailbox (foaf:mbox) but don't want to reveal its address, you can take that address and generate afoaf:mbox_sha1sum representation of it. Just as afoaf:mbox can be used as an indirect identifier for its owner, we can do the same withfoaf:mbox_sha1sum since there is only onefoaf:Person with any particular value for that property.

Many FOAF tools usefoaf:mbox_sha1sum in preference to exposing mailbox information. This is usually for privacy and SPAM-avoidance reasons. Other relevant techniques include the use of PGP encryption (seeEdd Dumbill's documentation) and the use ofFOAF-based whitelists for mail filtering.

Code examples for SHA1 in C#, Java, PHP, Perl and Python can be foundin Sam Ruby's weblog entry. Remember to include the 'mailto:' prefix, but no trailing whitespace, when computing afoaf:mbox_sha1sum property.

[back to top]

Property: foaf:member

Thefoaf:member property relates afoaf:Group to afoaf:Agent that is a member of that group.

Seefoaf:Group for details and examples.

[back to top]

Property: foaf:membershipClass

Thefoaf:membershipClass property relates afoaf:Group to an RDF class representing a sub-class offoaf:Agent whose instances are all the agents that are afoaf:member of thefoaf:Group.

Seefoaf:Group for details and examples.

[back to top]

Property: foaf:msnChatID

Thefoaf:msnChatID property relates afoaf:Agent to a textual identifier assigned to them in the MSN online Chat system. See Microsoft's theMSN chat site for more details (or for a message saying"MSN Chat is not currently compatible with your Internet browser and/or computer operating system" if your computing platform is deemed unsuitable).

It is not currently clear how MSN chat IDs relate to the more general Microsoft Passport identifiers.

Seefoaf:OnlineChatAccount (andfoaf:OnlineAccount) for a more general (and verbose) mechanism for describing IM and chat accounts.

[back to top]

Property: foaf:myersBriggs

Thefoaf:myersBriggs property represents the Myers Briggs (MBTI) approach to personality taxonomy. It is included in FOAF as an example of a property that takes certain constrained values, and to give some additional detail to the FOAF files of those who choose to include it. Thefoaf:myersBriggs property applies only to thefoaf:Person class; wherever you see it, you can infer it is being applied to a person.

Thefoaf:myersBriggs property is interesting in that it illustrates how FOAF can serve as a carrier for various kinds of information, without necessarily being commited to any associated worldview. Not everyone will find myersBriggs (or star signs, or blood types, or the four humours) a useful perspective on human behaviour and personality. The inclusion of a Myers Briggs property doesn't indicate that FOAF endorses the underlying theory, any more than the existence offoaf:weblog is an endorsement of soapboxes.

The values forfoaf:myersBriggs are the following 16 4-letter textual codes: ESTJ, INFP, ESFP, INTJ, ESFJ, INTP, ENFP, ISTJ, ESTP, INFJ, ENFJ, ISTP, ENTJ, ISFP, ENTP, ISFJ. If multiple of these properties are applicable, they are represented by applying multiple properties to a person.

For further reading on MBTI, see various online sources (eg.this article). There are various online sites which offer quiz-based tools for determining a person's MBTI classification. The owners of the MBTI trademark have probably not approved of these.

This FOAF property suggests some interesting uses, some of which could perhaps be used to test the claims made by proponents of the MBTI (eg. an analysis of weblog postings filtered by MBTI type). However it should be noted that MBTI FOAF descriptions are self-selecting; MBTI categories may not be uniformly appealing to the people they describe. Further, there is probably a degree of cultural specificity implicit in the assumptions made by many questionaire-based MBTI tools; the MBTI system may not make sense in cultural settings beyond those it was created for.

See alsoCory Caplinger's summary table or the RDFWeb article,FOAF Myers Briggs addition for further background and examples.

Note: Myers Briggs Type Indicator and MBTI are registered trademarks of Consulting Psychologists Press Inc. Oxford Psycholgists Press Ltd has exclusive rights to the trademark in the UK.

[back to top]

Property: foaf:name

Thefoaf:name of something is a simple textual string.

XML language tagging may be used to indicate the language of the name. For example:

FOAF provides some other naming constructs. While foaf:name does not explicitly represent name substructure (family vs given etc.) it does provide a basic level of interoperability. See theissue tracker for status of work on this issue.

Thefoaf:name property, like all RDF properties with a range of rdfs:Literal, may be used with XMLLiteral datatyped values. This usage is, however, not yet widely adopted. Feedback on this aspect of the FOAF design is particularly welcomed.

[back to top]

Property: foaf:nick

Thefoaf:nick property relates afoaf:Person to a short (often abbreviated) nickname, such as those use in IRC chat, online accounts, and computer logins.

This property is necessarily vague, because it does not indicate any particular naming control authority, and so cannot distinguish a person's login from their (possibly various) IRC nicknames or other similar identifiers. However it has some utility, since many people use the same string (or slight variants) across a variety of such environments.

For specific controlled sets of names (relating primarily to Instant Messanger accounts), FOAF provides some convenience properties:foaf:jabberID,foaf:aimChatID,foaf:msnChatID andfoaf:icqChatID. Beyond this, the problem of representing such accounts is not peculiar to Instant Messanging, and it is not scaleable to attempt to enumerate each naming database as a distinct FOAF property. Thefoaf:OnlineAccount term (and supporting vocabulary) are provided as a more verbose and more expressive generalisation of these properties.

[back to top]

Property: foaf:page

Thefoaf:page property relates a thing to a document about that thing.

As such it is an inverse of thefoaf:topic property, which relates a document to a thing that the document is about.

[back to top]

Property: foaf:pastProject

After afoaf:Person is no longer involved with afoaf:currentProject, or has been inactive for some time, afoaf:pastProject relationship can be used. This indicates thatthefoaf:Person was involved with the described project at onepoint.

If thefoaf:Person has stopped working on a project because it has been completed (successfully or otherwise),foaf:pastProject is applicable. In general,foaf:currentProject is used to indicate someone's current efforts (and implied interests, concerns etc.), whilefoaf:pastProject describes what they've previously been doing.

[back to top]

Property: foaf:phone

Thefoaf:phone of something is a phone, typically identified using the tel: URI scheme.

[back to top]

Property: foaf:plan

Thefoaf:plan property provides a space for afoaf:Person to hold some arbitrary content that would appear ina traditional '.plan' file. The plan file was stored in a user's homedirectory on a UNIX machine, and displayed to people when the user wasqueried with the finger utility.

A plan file could contain anything. Typical uses included briefcomments, thoughts, or remarks on what a person had been doing lately. Planfiles were also prone to being witty or simply osbscure. Others may be morecreative, writing any number of seemingly random compositions in their planfile for people to stumble upon.

SeeHistory of the Finger Protocol by Rajiv Shah for more on this piece of Internet history. Thefoaf:geekcode property may also be of interest.

[back to top]

Property: foaf:primaryTopic

Thefoaf:primaryTopic property relates a document to themain thing that the document is about.

Thefoaf:primaryTopic property isfunctional: forany document it applies to, it can have at most one value. This isuseful, as it allows for data merging. In many cases it may be difficultfor third parties to determine the primary topic of a document, but ina useful number of cases (eg. descriptions of movies, restaurants,politicians, ...) it should be reasonably obvious. Documents are veryoften the most authoritative source of information about their ownprimary topics, although this cannot be guaranteed since documents cannot beassumed to be accurate, honest etc.

It is an inverse of thefoaf:isPrimaryTopicOf property, which relates a thing to a documentprimarily about that thing. The choice between these two properties is purely pragmatic. When describing documents, we usefoaf:primaryTopic former to point to the things they're about. When describing things (people etc.), it is useful to be able to directly cite documents which have those things as their main topic - so we usefoaf:isPrimaryTopicOf. In this way, Web sites such asWikipedia orNNDB can provide indirect identification for the things they have descriptions of.

[back to top]

Property: foaf:publications

Thefoaf:publications property indicates afoaf:Documentlisting (primarily in human-readable form) some publications associated with thefoaf:Person. Such documents are typically published alongside one'sfoaf:homepage.

[back to top]

Property: foaf:schoolHomepage

TheschoolHomepage property relates afoaf:Person to afoaf:Document that is thefoaf:homepage of a School that the person attended.

FOAF does not (currently) define a class for 'School' (if it did, it would probably be as a sub-class offoaf:Organization). The original application area forfoaf:schoolHomepage was for 'schools' in the British-English sense; however American-English usage has dominated, and it is now perfectly reasonable to describe Universities, Colleges and post-graduate study usingfoaf:schoolHomepage.

This very basic facility provides a basis for a low-cost, decentralised approach to classmate-reunion and suchlike. Instead of requiring a central database, we can use FOAF to express claims such as 'I studiedhere' simply by mentioning a school's homepage within FOAF files. Given the homepage of a school, it is easy for FOAF aggregators to lookup this property in search of people who attended that school.

[back to top]

Property: foaf:sha1

Thefoaf:sha1 property relates afoaf:Document to the textual form of a SHA1 hash of (some representation of) its contents.

The design for this property is neither complete nor coherent. Thefoaf:Document class is currently used in a way that allows multiple instances at different URIs to have the 'same' contents (and hence hash). Iffoaf:sha1 is an owl:InverseFunctionalProperty, we could deduce that several such documents were the self-same thing. A more careful design is needed, which distinguishes documents in a broad sense from byte sequences.

[back to top]

Property: foaf:surname

A number of naming constructs are under development to providenaming substructure; draft properties includefoaf:firstName,foaf:givenname, andfoaf:surname. These are not currently stable or consistent; see theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simplefoaf:name property.

[back to top]

Property: foaf:theme

Thefoaf:theme property is rarely used and under-specified. The intention was to use it to characterise interest / themes associated with projects and groups. Further work is needed to meet these goals.

[back to top]

Property: foaf:thumbnail

Thefoaf:thumbnail property is a relationship between a full-sizefoaf:Image and a smaller, representativefoaf:Image that has been derrived from it.

It is typical in FOAF to expressfoaf:img andfoaf:depiction relationships in terms of the larger, 'main' (in some sense) image, rather than its thumbnail(s). Afoaf:thumbnail might be clipped or otherwise reduced such that it does not depict everything that the full image depicts. Therefore FOAF does not specify that a thumbnailfoaf:depicts everything that the image it is derrived from depicts.However, FOAF does expect that anything depicted in the thumbnail will also be depicted in the source image.

Afoaf:thumbnail is typically small enough that it can beloaded and viewed quickly before a viewer decides to download the largerversion. They are often used in online photo gallery applications.

[back to top]

Property: foaf:tipjar

Thefoaf:tipjar property relates anfoaf:Agentto afoaf:Document that describes some mechanisms forpaying or otherwise rewarding that agent.

Thefoaf:tipjar property was created followingdiscussions about simple, lightweight mechanisms that could be used to encourage rewards and payment for content exchanged online. An agent'sfoaf:tipjar page(s) could describe informal ("Send me apostcard!", "here's my book, music and movie wishlist") or formal(machine-readable micropayment information) information about how thatagent can be paid or rewarded. The reward is not associated with anyparticular action or content from the agent concerned. A link to a service such asPayPal is thesort of thing we might expect to find in a tipjar document.

Note that the value of afoaf:tipjar property is just adocument (which can include anchors into HTML pages). We expect, but do not currently specify, that this will evolve into a hookfor finding more machine-readable information to support payments,rewards. Thefoaf:OnlineAccount machinery is also relevant,although the information requirements for automating payments are not currently clear.

[back to top]

Property: foaf:title

The approriate values forfoaf:title are not formally constrained, and will vary across community and context. Values such as 'Mr', 'Mrs', 'Ms', 'Dr' etc. are expected.

[back to top]

Property: foaf:topic

Thefoaf:topic property relates a document to a thing that the document is about.

As such it is an inverse of thefoaf:page property, which relates a thing to a document about that thing.

[back to top]

Property: foaf:topic_interest

Thefoaf:topic_interest property is generally found to be confusing and ill-defined and is a candidate for removal. The goal was to be link a person to some thing that is a topic of their interests (rather than, perfoaf:interest to a page that is about such a topic).

[back to top]

Property: foaf:weblog

Thefoaf:weblog property relates afoaf:Agent to a weblog of that agent.

[back to top]

Property: foaf:workInfoHomepage

Thefoaf:workInfoHomepage of afoaf:Person is afoaf:Document that describes their work. It is generally (but not necessarily) a different document from theirfoaf:homepage, and from anyfoaf:workplaceHomepage(s) they may have.

The purpose of this property is to distinguish those pages you often see, which describe someone's professional role within an organisation or project. These aren't really homepages, although they share some characterstics.

[back to top]

Property: foaf:workplaceHomepage

Thefoaf:workplaceHomepage of afoaf:Person is afoaf:Document that is thefoaf:homepage of afoaf:Organization that they work for.

By directly relating people to the homepages of their workplace, we have a simple convention that takes advantage of a set of widely known identifiers, while taking care not to confuse the things those identifiers identify (ie. organizational homepages) with the actual organizations those homepages describe.

<foaf:Person> <foaf:name>Dan Brickley</foaf:name> <foaf:workplaceHomepage rdf:resource="http://www.w3.org/"/></foaf:Person>

Note that several other FOAF properties work this way;foaf:schoolHomepage is the most similar. In general, FOAF often indirectly identifies things via Web page identifiers where possible, since these identifiers are widely used and known. FOAF does not currently have a term for the name of the relation (eg. "workplace") that holds between afoaf:Person and anfoaf:Organization that they work for.

[back to top]

Property: foaf:yahooChatID

Thefoaf:yahooChatID property relates afoaf:Agent to a textual identifier assigned to them in the Yahoo online Chat system. See Yahoo's theYahoo! Chat site for more details of their service. Yahoo chat IDs are also used across several other Yahoo services, including email andYahoo! Groups.

Seefoaf:OnlineChatAccount (andfoaf:OnlineAccount) for amore general (and verbose) mechanism for describing IM and chat accounts.

[back to top]