FOAF Vocabulary Specification 0.98

Property: foaf:homepage

The homepage property relates something to a homepage about it.

Many kinds of things have homepages. FOAF allows a thing to have multiple homepages, but constrains 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 a 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.

The homepage property is a sub-property of the more general page property for relating a thing to a page about that thing. See also topic, the inverse of the page property.

[#] [wiki] [back to top]

Property: foaf:isPrimaryTopicOf

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

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

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

Note that homepage, is a sub-property of both page and isPrimaryTopicOf. The awkwardly named isPrimaryTopicOf is less specific, and can be used with any document that is primarily about the thing of interest (ie. not just on homepages).

[#] [wiki] [back to top]

Property: foaf:knows

The knows property relates a Person to another 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 someone 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. A 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...).

Since 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 each weblog that was made by someone you "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 than knows to relate people to people. The original FOAF design included two of these ('knowsWell','friend') which we removed because they were somewhat awkward to actually use, bringing an inappopriate air of precision to an intrinsically vague concept. Other extensions have been proposed, including Eric Vitiello's Relationship 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 their 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 a Document that has two people listed as its 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 of knows is, alongside the rdfs: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 (via knows or other relationships), and by providing an rdfs: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...

[#] [wiki] [back to top]

Property: foaf:made

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

[#] [wiki] [back to top]

Property: foaf:maker

The maker property relates something to a Agent that made it. As such it is an inverse of the made property.

The name (or other rdfs:label) of the maker of something can be described as the dc:creator of that thing.

For example, if the thing named by the URI http://danbri.org/ has a maker that is a Person whose name is 'Dan Brickley', we can conclude that http://danbri.org/ has a dc:creator of 'Dan Brickley'.

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

[#] [wiki] [back to top]

Property: foaf:mbox

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

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

In FOAF, we often see 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 the 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.

[#] [wiki] [back to top]

Property: foaf:member

The member property relates a Group to a Agent that is a member of that group.

See Group for details and examples.

[#] [wiki] [back to top]

Property: foaf:primaryTopic

The primaryTopic property relates a document to the main thing that the document is about.

The primaryTopic property is functional: for any document it applies to, it can have at most one value. This is useful, as it allows for data merging. In many cases it may be difficult for third parties to determine the primary topic of a document, but in a useful number of cases (eg. descriptions of movies, restaurants, politicians, ...) it should be reasonably obvious. Documents are very often the most authoritative source of information about their own primary topics, although this cannot be guaranteed since documents cannot be assumed to be accurate, honest etc.

It is an inverse of the isPrimaryTopicOf property, which relates a thing to a document primarily about that thing. The choice between these two properties is purely pragmatic. When describing documents, we use 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 use isPrimaryTopicOf. In this way, Web sites such as Wikipedia or NNDB can provide indirect identification for the things they have descriptions of.

[#] [wiki] [back to top]

Property: foaf:account

The account property relates a Agent to an OnlineAccount for which they are the sole account holder. See OnlineAccount for usage details.

[#] [wiki] [back to top]

Property: foaf:accountName

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

[#] [wiki] [back to top]

Property: foaf:accountServiceHomepage

The accountServiceHomepage property indicates a relationship between a OnlineAccount and the homepage of the supporting service provider.

[#] [wiki] [back to top]

Property: foaf:aimChatID

The aimChatID property relates a Agent to a textual identifier ('screenname') assigned to them in the AOL Instant Messanger (AIM) system. See AOL's AIM site for more details of AIM and AIM screennames. The iChat tools from Apple also make use of AIM identifiers.

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

[#] [wiki] [back to top]

Property: foaf:based_near

The based_near relationship relates two "spatial things" (anything that can be somewhere), the latter typically described using the geo:lat / geo:long geo-positioning vocabulary (See GeoInfo in the W3C semweb wiki 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, see GeoOnion vocab design discussions, which are aiming to produce a more sophisticated vocabulary for such purposes.

FOAF files often make use of the contact:nearestAirport property. This illustrates the distinction between FOAF documents (which may make claims using any RDF vocabulary) and the core FOAF vocabulary defined by this specification. For further reading on the use of nearestAirport see UsingContactNearestAirport in the FOAF wiki.

[#] [wiki] [back to top]

Property: foaf:currentProject

A currentProject relates a Person to a Document indicating some collaborative or individual undertaking. This relationship indicates that the Person has some active role in the project, such as development, coordination, or support.

When a Person is no longer involved with a project, or perhaps is inactive for some time, the relationship becomes a pastProject.

If the Person has stopped working on a project because it has been completed (successfully or otherwise), pastProject is applicable. In general, currentProject is used to indicate someone's current efforts (and implied interests, concerns etc.), while 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. a Document or to instances of the class Project, which might themselves have a homepage. In practice, it seems to have been used in a similar way to interest, referencing homepages of ongoing projects.

[#] [wiki] [back to top]

Property: foaf:depiction

The depiction property is a relationship between a thing and an Image that depicts it. As such it is an inverse of the depicts relationship.

A common use of depiction (and 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 the regions 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.

The depiction property is a super-property of the more specific property img, which is used more sparingly. You stand in a depiction relation to any Image that depicts you, whereas img is typically used to indicate a few images that are particularly representative.

[#] [wiki] [back to top]

Property: foaf:depicts

The depicts property is a relationship between a Image and something that the image depicts. As such it is an inverse of the depiction relationship. See depiction for further notes.

[#] [wiki] [back to top]

Property: foaf:familyName

The familyName property is provided (alongside givenName) for use when describing parts of people's names. Although these concepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.

There is also a simple name property.

Support is also provided for the more archaic and culturally varying terminology of firstName and lastName.

See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

[#] [wiki] [back to top]

Property: foaf:firstName

The firstName property is provided (alongside lastName) as a mechanism to support legacy data that cannot be easily interpreted in terms of the (otherwise preferred) familyName and givenName properties. The concepts of 'first' and 'last' names do not work well across cultural and linguistic boundaries; however they are widely used in addressbooks and databases.

See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simple name property.

[#] [wiki] [back to top]

Property: foaf:focus

The focus property relates a conceptualisation of something to the thing itself. Specifically, it is designed for use with W3C's SKOS vocabulary, to help indicate specific individual things (typically people, places, artifacts) that are mentioned in different SKOS schemes (eg. thesauri).

W3C SKOS is based around collections of linked 'concepts', which indicate topics, subject areas and categories. In SKOS, properties of a skos:Concept are properties of the conceptualization (see 2005 discussion for details); for example administrative and record-keeping metadata. Two schemes might have an entry for the same individual; the foaf:focus property can be used to indicate the thing in they world that they both focus on. Many SKOS concepts don't work this way; broad topical areas and subject categories don't typically correspond to some particular entity. However, in cases when they do, it is useful to link both subject-oriented and thing-oriented information via foaf:focus.

FOAF's focus property works alongside its other topic-oriented constructs: topic, primaryTopic are used when talking about the topical emphasis of a document. The notion of primaryTopic is particularly important in FOAF as it provides an indirect mechanism for identifying things indirectly. A similar approach is explored by the TDB URI scheme. FOAF includes topic-oriented functionality to address its original goals of linking people to information, as well as to other people, through the use of linked information.

[#] [wiki] [back to top]

Property: foaf:gender

The gender property relates a Agent (typically a 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 use gender in any particular document or description. Values other than 'male' and 'female' may be used, but are not enumerated here. The gender mechanism is not intended to capture the full variety of biological, social and sexual concepts associated with the word 'gender'.

Anything that has a gender property will be some kind of Agent. However there are kinds of Agent to which the concept of gender isn't applicable (eg. a Group). FOAF does not currently include a class corresponding directly to "the type of thing that has a gender". At any point in time, a Agent has at most one value for gender. FOAF does not treat gender as a static 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 all 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 their gender. Feedback on this design is particularly welcome (via the FOAF mailing list, foaf-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 'gender' will on occassion be innacurate, misleading or outright false. FOAF, like all open means of communication, supports lying. 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 omit 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.

[#] [wiki] [back to top]

Property: foaf:givenName

The givenName property is provided (alongside familyName) for use when describing parts of people's names. Although these concepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.

There is also a simple name property.

Support is also provided for the more archaic and culturally varying terminology of firstName and lastName.

See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

[#] [wiki] [back to top]

Property: foaf:icqChatID

The icqChatID property relates a Agent to a textual identifier assigned to them in the ICQ Chat system. See the icq 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 (see aimChatID).

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

[#] [wiki] [back to top]

Property: foaf:img

The img property relates a Person to a Image that represents them. Unlike its super-property depiction, we only use 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 general depiction property (and its inverse, depicts), the img property is only used with representations of people (ie. instances of 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 than depiction so we can have a useful way of picking out a reasonable image to represent someone. FOAF defines img as a sub-property of depiction, which means that the latter relationship is implied whenever two things are related by the former.

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

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

[#] [wiki] [back to top]

Property: foaf:interest

The interest property represents an interest of a Agent, through indicating a Document whose topic(s) broadly characterises that interest.

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

Uses of 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 to CPAN)".

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's interest. Describing interests in full is a complex undertaking; interest provides one basic component of FOAF's approach to these problems.

[#] [wiki] [back to top]

Property: foaf:jabberID

The jabberID property relates a Agent to a textual identifier assigned to them in the Jabber messaging system. See the Jabber 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 of Agent (ie. things that do stuff). The uses of Jabber go beyond simple IM chat applications. The jabberID property is provided as a basic hook to help support RDF description of Jabber users and services.

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

[#] [wiki] [back to top]

Property: foaf:lastName

The lastName property is provided (alongside firstName) as a mechanism to support legacy data that cannot be easily interpreted in terms of the (otherwise preferred) familyName and givenName properties. The concepts of 'first' and 'last' names do not work well across cultural and linguistic boundaries; however they are widely used in addressbooks and databases.

See the issue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.

There is also a simple name property.

[#] [wiki] [back to top]

Property: foaf:logo

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

[#] [wiki] [back to top]

Property: foaf:mbox_sha1sum

A mbox_sha1sum of a 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 a mbox relationship to.

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

Many FOAF tools use 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 (see Edd Dumbill's documentation) and the use of FOAF-based whitelists for mail filtering.

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

[#] [wiki] [back to top]

Property: foaf:msnChatID

The msnChatID property relates a Agent to a textual identifier assigned to them in the Microsoft online chat system originally known as 'MSN', and now Windows Live Messenger. See the Microsoft mesenger and Windows Live ID sites for more details.

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

[#] [wiki] [back to top]

Property: foaf:myersBriggs

The 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. The myersBriggs property applies only to the Person class; wherever you see it, you can infer it is being applied to a person.

The 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 of weblog is an endorsement of soapboxes.

The values for 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 also Cory 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.

[#] [wiki] [back to top]

Property: foaf:name

The 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 the issue tracker for status of work on this issue.

The name property, like all RDF properties with a range of rdfs:Literal, may be used with XMLLiteral datatyped values (multiple names are acceptable whether they are in the same langauge or not). XMLLiteral usage is not yet widely adopted. Feedback on this aspect of the FOAF design is particularly welcomed.

[#] [wiki] [back to top]

Property: foaf:nick

The nick property relates a 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: jabberID, aimChatID, msnChatID and 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. The OnlineAccount term (and supporting vocabulary) are provided as a more verbose and more expressive generalisation of these properties.

[#] [wiki] [back to top]

Property: foaf:openid

A openid is a property of a Agent that associates it with a document that can be used as an indirect identifier in the manner of the OpenID "Identity URL". As the OpenID 1.1 specification notes, OpenID itself"does not provide any mechanism to exchange profile information, though Consumers of an Identity can learn more about an End User from any public, semantically interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.)". In this way, FOAF and OpenID complement each other; neither provides a stand-alone approach to online "trust", but combined they can address interesting parts of this larger problem space.

The openid property is "inverse functional", meaning that anything that is the foaf:openid of something, is the openid of no more than one thing. FOAF is agnostic as to whether there are (according to the relevant OpenID specifications) OpenID URIs that are equally associated with multiple Agents. FOAF offers sub-classes of Agent, ie. Organization and Group, that allow for such scenarios to be consistent with the notion that any foaf:openid is the foaf:openid of just one Agent.

FOAF does not mandate any particular URI scheme for use as openid values. The OpenID 1.1 specification includes a delegation model that is often used to allow a weblog or homepage document to also serve in OpenID authentication via "link rel" HTML markup. This deployment model provides a convenient connection to FOAF, since a similar technique is used for FOAF autodiscovery in HTML. A single document can, for example, serve both as a homepage and an OpenID identity URL.

[#] [wiki] [back to top]

Property: foaf:page

The page property relates a thing to a document about that thing.

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

[#] [wiki] [back to top]

Property: foaf:pastProject

After a Person is no longer involved with a currentProject, or has been inactive for some time, a pastProject relationship can be used. This indicates that the Person was involved with the described project at one point.

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

[#] [wiki] [back to top]

Property: foaf:phone

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

[#] [wiki] [back to top]

Property: foaf:plan

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

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

See History of the Finger Protocol by Rajiv Shah for more on this piece of Internet history. The geekcode property may also be of interest.

[#] [wiki] [back to top]

Property: foaf:publications

The publications property indicates a Document listing (primarily in human-readable form) some publications associated with the Person. Such documents are typically published alongside one's homepage.

[#] [wiki] [back to top]

Property: foaf:schoolHomepage

The schoolHomepage property relates a Person to a Document that is the 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 of Organization). The original application area for 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 using 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 studied here' 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.

[#] [wiki] [back to top]

Property: foaf:skypeID

The skype property relates a Agent to an account name of a Skype account of theirs.

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

[#] [wiki] [back to top]

Property: foaf:thumbnail

The thumbnail property is a relationship between a full-size Image and a smaller, representative Image that has been derrived from it.

It is typical in FOAF to express img and depiction relationships in terms of the larger, 'main' (in some sense) image, rather than its thumbnail(s). A 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 thumbnail 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.

A thumbnail is typically small enough that it can be loaded and viewed quickly before a viewer decides to download the larger version. They are often used in online photo gallery applications.

[#] [wiki] [back to top]

Property: foaf:tipjar

The tipjar property relates an Agent to a Document that describes some mechanisms for paying or otherwise rewarding that agent.

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

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

[#] [wiki] [back to top]

Property: foaf:title

This property is a candidate for deprecation in favour of 'honorificPrefix' following Portable Contacts usage. See the FOAF Issue Tracker.

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

[#] [wiki] [back to top]

Property: foaf:topic

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

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

[#] [wiki] [back to top]

Property: foaf:topic_interest

The topic_interest property links a Agent to a thing that they're interested in. Unlike topic it is not indirected through a document, but links the thing directly.

[#] [wiki] [back to top]

Property: foaf:weblog

The weblog property relates a Agent to a weblog of that agent.

[#] [wiki] [back to top]

Property: foaf:workInfoHomepage

The workInfoHomepage of a Person is a Document that describes their work. It is generally (but not necessarily) a different document from their homepage, and from any 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.

[#] [wiki] [back to top]

Property: foaf:workplaceHomepage

The workplaceHomepage of a Person is a Document that is the homepage of a 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; 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 a Person and an Organization that they work for.

[#] [wiki] [back to top]

Property: foaf:yahooChatID

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

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

[#] [wiki] [back to top]

Property: foaf:age

The age property is a relationship between a Agent and an integer string representing their age in years. See also birthday.

[#] [wiki] [back to top]

Property: foaf:birthday

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

See also age.

[#] [wiki] [back to top]

Property: foaf:membershipClass

The membershipClass property relates a Group to an RDF class representing a sub-class of Agent whose instances are all the agents that are a member of the Group.

See Group for details and examples.

[#] [wiki] [back to top]

Property: foaf:sha1

The sha1 property relates a 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. The Document class is currently used in a way that allows multiple instances at different URIs to have the 'same' contents (and hence hash). If 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.

[#] [wiki] [back to top]

Property: foaf:status

status is a short textual string expressing what the user is happy for the general public (normally) to know about their current activity. mood, location, etc.

[#] [wiki] [back to top]