Copyright © 2000-2014 Dan Brickley and Libby Miller
This work is licensed under a Creative Commons Attribution License.
This copyright applies to the FOAF Vocabulary Specification and accompanying documentation in RDF. Regarding underlying technology, FOAF uses W3C's RDF technology, an open Web standard that can be freely used by anyone.
This specification describes the FOAF language, defined as a dictionary of named properties and classes using W3C's RDF technology.
FOAF is a project devoted to linking people and information using the Web. Regardless of whether information is in people's heads, in physical or digital documents, or in the form of factual data, it can be linked. FOAF integrates three kinds of network: social networks of human collaboration, friendship and association; representational networks that describe a simplified view of a cartoon universe in factual terms, and information networks that use Web-based linking to share independently published descriptions of this inter-connected world. FOAF does not compete with socially-oriented Web sites; rather it provides an approach in which different sites can tell different parts of the larger story, and by which users can retain some control over their information in a non-proprietary format.
FOAF has been evolving gradually since its creation in mid-2000. There is now a stable core of classes and properties that will not be changed, beyond modest adjustments to their documentation to track implementation feedback and emerging best practices. New terms may be added at any time (as with a natural-language dictionary), and consequently this specification is an evolving work. The FOAF RDF namespace URI, by contrast, is fixed and its identifier is not expected to change. Furthermore, efforts are underway to ensure the long-term preservation of the FOAF namespace, its xmlns.com domain name and associated documentation.
The FOAF specification is produced as part of the FOAF project, to provide authoritative documentation of the contents, status and purpose of the RDF/XML vocabulary and document formats known informally as 'FOAF'.
This document is created by combining the RDFS/OWL machine-readable FOAF ontology with a set of per-term documents. Future versions may incorporate multilingual translations of the term definitions. An RDF/XML encoding of the specification is available by direct link or by HTTP content negotiation from the namespace URI. The HTML specification no longer embeds the RDF/XML markup; however an experimental subset of the RDF is included in this document using RDFa notation.
The authors welcome comments on this document, preferably via the public FOAF developers list foaf-dev@lists.foaf-project.org; public archives are available. A historical backlog of known technical issues is acknowledged, and available for discussion on the FOAF mailing list. Proposals for resolving these issues are welcomed, on foaf-dev. Further work is also needed on the explanatory text in this specification and on the FOAF website; progress towards this will be measured in the version number of future revisions to the FOAF specification.
This revision stablises weblog, page, Document and Image and adds three owl:equivalent classes to schema.org - Person (Person), Image (ImageObject), Document (CreativeWork).
See the changes section for more detailed change-log information.
FOAF describes the world using simple ideas inspired by the Web. In FOAF descriptions, there are only various kinds of things and links, which we call properties. The types of the things we talk about in FOAF are called classes. FOAF is therefore defined as a dictionary of terms, each of which is either a class or a property. Other projects alongside FOAF provide other sets of classes and properties, many of which are linked with those defined in FOAF.
FOAF descriptions are themselves published as linked documents in the Web (eg. using RDF/XML or RDFa syntax). The result of the FOAF project is a network of documents describing a network of people (and other stuff). Each FOAF document is itself an encoding of a descriptive network structure. Although these documents do not always agree or tell the truth, they have the useful characteristic that they can be easily merged, allowing partial and decentralised descriptions to be combined in interesting ways.
FOAF collects a variety of terms; some describe people, some groups, some documents. Different kinds of application can use or ignore different parts of FOAF. The overview here shows one way of viewing FOAF terms: we ignore archaic and historical parts, and divide the rest into terms that only make sense on the Web, and those that have universal applicability when linking people and information.
Main FOAF terms, grouped in broad categories.
This is a complete alphabetical A-Z index of all FOAF terms, by class (categories or types) and by property. Note that it includes 'archaic' terms that are largely of historical interest.
Classes: | Agent | Document | Group | Image | LabelProperty | OnlineAccount | OnlineChatAccount | OnlineEcommerceAccount | OnlineGamingAccount | Organization | Person | PersonalProfileDocument | Project |
Properties: | account | accountName | accountServiceHomepage | age | aimChatID | based_near | birthday | currentProject | depiction | depicts | dnaChecksum | familyName | family_name | firstName | focus | fundedBy | geekcode | gender | givenName | givenname | holdsAccount | homepage | icqChatID | img | interest | isPrimaryTopicOf | jabberID | knows | lastName | logo | made | maker | mbox | mbox_sha1sum | member | membershipClass | msnChatID | myersBriggs | name | nick | openid | page | pastProject | phone | plan | primaryTopic | publications | schoolHomepage | sha1 | skypeID | status | surname | theme | thumbnail | tipjar | title | topic | topic_interest | weblog | workInfoHomepage | workplaceHomepage | yahooChatID |
Here is a very basic document describing a person:
<foaf:Person rdf:about="#danbri" xmlns:foaf="https://www.downtownmelody.com/_x/eG1sbnMuY29t/foaf/0.1/"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="https://www.downtownmelody.com/_x/ZGFuYnJpLm9yZw/" /> <foaf:openid rdf:resource="https://www.downtownmelody.com/_x/ZGFuYnJpLm9yZw/" /> <foaf:img rdf:resource="/images/me.jpg" /> </foaf:Person>
This brief example introduces the basics of FOAF. It basically says, "there is a foaf:Person with a foaf:name property of 'Dan Brickley'; this person stands in foaf:homepage and foaf:openid relationship to a thing called https://www.downtownmelody.com/_x/ZGFuYnJpLm9yZw/ and a foaf:img relationship to a thing referenced by a relative URI of /images/me.jpg
To a computer, the Web is a flat, boring world, devoid of meaning. This is a pity, as in fact documents on the Web describe real objects and imaginary concepts, and give particular relationships between them. For example, a document might describe a person. The title document to a house describes a house and also the ownership relation with a person. Adding semantics to the Web involves two things: allowing documents which have information in machine-readable forms, and allowing links to be created with relationship values. Only when we have this extra level of semantics will we be able to use computer power to help us exploit the information to a greater extent than our own reading. - Tim Berners-Lee "W3 future directions" keynote, 1st World Wide Web Conference Geneva, May 1994
I express my network in a FOAF file, and that is a start of the revolution. - TimBL 2007, Giant Global Graph (foaf)
FOAF is a project devoted to linking people and information using the Web. Regardless of whether information is in people's heads, in physical or digital documents, or in the form of factual data, it can be linked. FOAF integrates three kinds of network: social networks of human collaboration, friendship and association; representational networks that describe a simplified view of a cartoon universe in factual terms, and information networks that use Web-based linking to share independently published descriptions of this inter-connected world. FOAF does not compete with socially-oriented Web sites; rather it provides an approach in which different sites can tell different parts of the larger story, and through which users can retain some control over their information in a non-proprietary format.
FOAF, like the Web itself, is a linked information system. It is built using decentralised Semantic Web technology, and has been designed to allow for integration of data across a variety of applications, Web sites and services, and software systems. To achieve this, FOAF takes a liberal approach to data exchange. It does not require you to say anything at all about yourself or others, nor does it place any limits on the things you can say or the variety of Semantic Web vocabularies you may use in doing so. This current specification provides a basic "dictionary" of terms for talking about people and the things they make and do.
FOAF was designed to be used alongside other such dictionaries ("schemas" or "ontologies"), and to be usable with the wide variety of generic tools and services that have been created for the Semantic Web. For example, the W3C work on SPARQL provides us with a rich query language for consulting databases of FOAF data, while the SKOS initiative explores in more detail than FOAF the problem of describing topics, categories, "folksonomies" and subject hierarchies. Meanwhile, other W3C groups are working on improved mechanisms for encoding all kinds of RDF data (including but not limited to FOAF) within Web pages: see the work of the GRDDL and RDFa efforts for more detail. The Semantic Web provides us with an architecture for collaboration, allowing complex technical challenges to be shared by a loosely-coordinated community of developers.
The FOAF project is based around the use of machine readable Web homepages for people, groups, companies and other kinds of thing. To achieve this we use the "FOAF vocabulary" to provide a collection of basic terms that can be used in these Web pages. At the heart of the FOAF project is a set of definitions designed to serve as a dictionary of terms that can be used to express claims about the world. The initial focus of FOAF has been on the description of people, since people are the things that link together most of the other kinds of things we describe in the Web: they make documents, attend meetings, are depicted in photos, and so on.
The FOAF Vocabulary definitions presented here are written using a computer language (RDF/OWL) that makes it easy for software to process some basic facts about the terms in the FOAF vocabulary, and consequently about the things described in FOAF documents. A FOAF document, unlike a traditional Web page, can be combined with other FOAF documents to create a unified database of information. FOAF is a Linked Data system, in that it based around the idea of linking together a Web of decentralised descriptions.
The basic idea is pretty simple. If people publish information in the FOAF document format, machines will be able to make use of that information. If those files contain "see also" references to other such documents in the Web, we will have a machine-friendly version of today's hypertext Web. Computer programs will be able to scutter around a Web of documents designed for machines rather than humans, storing the information they find, keeping a list of "see also" pointers to other documents, checking digital signatures (for the security minded) and building Web pages and question-answering services based on the harvested documents.
So, what is the 'FOAF document format'? FOAF files are just
text documents (well, Unicode documents). They adopt the conventions
of the Resource Description Framework (RDF), and may be written in XML
syntax or any other of the syntaxes of RDF such as RDFa or N3.
In addition, the FOAF vocabulary defines some
useful constructs that can appear in FOAF files, alongside other
RDF vocabularies defined elsewhere. For example, FOAF defines
categories ('classes') such as foaf:Person,
foaf:Document, foaf:Image, alongside
some handy properties of those things, such as
foaf:name, foaf:mbox (ie. an internet
mailbox), foaf:homepage etc., as well as some useful
kinds of relationship that hold between members of these
categories. For example, one interesting relationship type is
foaf:depiction. This relates something (eg. a
foaf:Person) to a foaf:Image. The FOAF
demos that feature photos and listings of 'who is in which
picture' are based on software tools that parse RDF documents and
make use of these properties.
The specific contents of the FOAF vocabulary are detailed in this FOAF namespace document. In addition to the FOAF vocabulary, one of the most interesting features of a FOAF file is that it can contain "see Also" pointers to other FOAF files. This provides a basis for automatic harvesting tools to traverse a Web of interlinked files, and learn about new people, documents, services, data...
The remainder of this specification describes how to publish and interpret descriptions such as these on the Web, using RDF/XML for syntax (file format) and terms from FOAF. It introduces a number of categories (RDF classes such as 'Person') and properties (relationship and attribute types such as 'mbox' or 'workplaceHomepage'). Each term definition is provided in both human and machine-readable form, hyperlinked for quick reference.
For an early general introduction to FOAF, see Edd Dumbill's article, XML Watch: Finding friends with XML and RDF (June 2002, IBM developerWorks). Information about the use of FOAF with image metadata is also available.
The co-depiction experiment shows a fun use of the vocabulary. To create a FOAF document, you can use Leigh Dodd's FOAF-a-matic javascript tool. For more information on FOAF and related projects, see the FOAF project home page.
FOAF is a collaborative effort amongst developers on the FOAF (foaf-dev@lists.foaf-project.org) mailing list. The name 'FOAF' is derived from traditional internet usage, an acronym for 'Friend of a Friend'.
The name was chosen to reflect our concern with social networks and the Web, urban myths, trust and connections. Other uses of the name continue, notably in the documentation and investigation of Urban Legends (eg. see the alt.folklore.urban archive or snopes.com), and other FOAF stories. Our use of the name 'FOAF' for a Web vocabulary and document format is intended to complement, rather than replace, these prior uses. FOAF documents describe the characteristics and relationships amongst friends of friends, and their friends, and the stories they tell.
It is important to understand that the FOAF vocabulary as specified in this document is not a standard in the sense of ISO Standardisation, or that associated with W3C Process.
FOAF depends heavily on W3C's standards work, specifically on XML, XML Namespaces, RDF, and OWL. All FOAF documents must be well-formed RDF documents. The FOAF vocabulary, by contrast, is managed more in the style of an Open Source or Free Software project than as an industry standardarisation effort (eg. see Jabber JEPs).
This specification contributes a vocabulary, "FOAF", to the Semantic Web, specifying it using W3C's Resource Description Framework (RDF). As such, FOAF adopts by reference both syntaxes (using XML, N3, or RDFa) a data model (RDF graphs) and a mathematically grounded definition for the rules that underpin the FOAF design.
This specification serves as the FOAF "namespace document". As such it describes the FOAF vocabulary the terms (RDF classes and properties) that constitute it, so that Semantic Web applications can use those terms in a variety of RDF-compatible document formats and applications.
This document presents FOAF as a Semantic Web vocabulary or Ontology. The FOAF vocabulary is pretty simple, pragmatic and designed to allow simultaneous deployment and extension. FOAF is intended for widescale use, but its authors make no commitments regarding its suitability for any particular purpose.
The FOAF vocabulary is identified by the namespace URI
'https://www.downtownmelody.com/_x/eG1sbnMuY29t/foaf/0.1/'. Revisions and
extensions of FOAF are conducted through edits to this document,
which by convention is accessible in the Web via the namespace URI.
For practical and deployment reasons, note that we do not
update the namespace URI as the vocabulary matures.
Much of FOAF now is considered stable. Each release of this specification document has an incrementally increased version number, even while the technical namespace ID remains fixed and includes the original value of "0.1". It long ago became impractical to update the namespace URI without causing huge disruption to both producers and consumers of FOAF data. We are left with the digits "0.1" in our URI. This stands as a warning to all those who might embed metadata in their vocabulary identifiers.
The evolution of FOAF is best considered in terms of the stability of individual vocabulary terms, rather than the specification as a whole. As terms stabilise in usage and documentation, they progress through the categories 'unstable', 'testing' and 'stable'. Older terms are marked 'archaic' which allows the possibility of older forms to become modern again.
The properties and types defined here provide some basic useful concepts for use in FOAF descriptions. Other vocabulary (eg. the Dublin Core metadata elements for simple bibliographic description), RSS 1.0 etc can also be mixed in with FOAF terms, as can local extensions. FOAF is designed to be extended.
If you publish a FOAF self-description (eg. using foaf-a-matic)
you can make it easier for tools to find your FOAF by putting
markup in the head of your HTML homepage. It doesn't
really matter what filename you choose for your FOAF document,
although foaf.rdf is a common choice. The linking
markup is as follows:
<link rel="meta" type="application/rdf+xml" title="FOAF"
href="https://www.downtownmelody.com/_x/ZXhhbXBsZS5jb20/~you/foaf.rdf"/>
...although of course change the URL to point to your own FOAF document. See also: more on FOAF autodiscovery and services that make use of it.
FOAF introduces the following classes and properties. A machine-friendly version is also available in RDF/XML.
Classes: | Agent | Document | Group | Image | LabelProperty | OnlineAccount | OnlineChatAccount | OnlineEcommerceAccount | OnlineGamingAccount | Organization | Person | PersonalProfileDocument | Project |
Properties: | account | accountName | accountServiceHomepage | age | aimChatID | based_near | birthday | currentProject | depiction | depicts | dnaChecksum | familyName | family_name | firstName | focus | fundedBy | geekcode | gender | givenName | givenname | holdsAccount | homepage | icqChatID | img | interest | isPrimaryTopicOf | jabberID | knows | lastName | logo | made | maker | mbox | mbox_sha1sum | member | membershipClass | msnChatID | myersBriggs | name | nick | openid | page | pastProject | phone | plan | primaryTopic | publications | schoolHomepage | sha1 | skypeID | status | surname | theme | thumbnail | tipjar | title | topic | topic_interest | weblog | workInfoHomepage | workplaceHomepage | yahooChatID |
| Status: | stable |
|---|---|
| Properties include: | gender yahooChatID account birthday icqChatID aimChatID jabberID made mbox interest tipjar skypeID topic_interest age mbox_sha1sum status msnChatID openid holdsAccount weblog |
| Used with: | maker member |
| Has Subclass | Group Person Organization |
The Agent class is the class of agents; things that do stuff. A well
known sub-class is Person, representing people. Other kinds of agents
include Organization and Group.
The Agent class is useful in a few places in FOAF where
Person would have been overly specific. For example, the IM chat ID
properties such as jabberID are typically associated with people, but
sometimes belong to software bots.
[#] [back to top]
| Status: | stable |
|---|---|
| Properties include: | topic primaryTopic sha1 |
| Used with: | workInfoHomepage workplaceHomepage page accountServiceHomepage openid tipjar schoolHomepage publications isPrimaryTopicOf interest homepage weblog |
| Has Subclass | Image PersonalProfileDocument |
| Disjoint With: | Project Organization |
The Document class represents those things which are, broadly conceived,
'documents'.
The Image class is a sub-class of 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 (see sha1
for related issues).
[#] [back to top]
| Status: | stable |
|---|---|
| Properties include: | member |
| Subclass Of | Agent |
The Group class represents a collection of individual agents (and may
itself play the role of a Agent, ie. something that can perform actions).
This concept is intentionally quite broad, covering informal and
ad-hoc groups, long-lived communities, organizational groups within a workplace, etc. Some
such groups may have associated characteristics which could be captured in RDF (perhaps a
homepage, name, mailing list etc.).
While a Group has the characteristics of a Agent, it
is also associated with a number of other Agents (typically people) who
constitute the Group. FOAF provides a mechanism, the
membershipClass property, which relates a Group to a
sub-class of the class Agent who are members of the group. This is a
little complicated, but allows us to make group membership rules explicit.
The markup (shown below) for defining a group is both complex and powerful. It
allows group membership rules to match against any RDF-describable characteristics of the potential
group members. As FOAF and similar vocabularies become more expressive in their ability to
describe individuals, the Group mechanism for categorising them into
groups also becomes more powerful.
While the formal description of membership criteria for a Group may
be complex, the basic mechanism for saying that someone is in a Group is
very simple. We simply use a member property of the
Group to indicate the agents that are members of the group. For example:
<foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:member> <foaf:Person> <foaf:name>Martin Poulter</foaf:name> <foaf:homepage rdf:resource="https://www.downtownmelody.com/_x/d3d3LmlscnQuYnJpcy5hYy51aw/aboutus/staff/staffprofile/?search=plmlp"/> <foaf:workplaceHomepage rdf:resource="https://www.downtownmelody.com/_x/d3d3LmlscnQuYnJpcy5hYy51aw/"/> </foaf:Person> </foaf:member> </foaf:Group>
Behind the scenes, further RDF statements can be used to express the rules for being a member of this group. End-users of FOAF need not pay attention to these details.
Here is an example. We define a Group representing those people who
are ILRT staff members (ILRT is a department at the University of Bristol). The membershipClass property connects the group (conceived of as a social
entity and agent in its own right) with the class definition for those people who
constitute it. In this case, the rule is that all group members are in the
ILRTStaffPerson class, which is in turn populated by all those things that are a
Person and which have a workplaceHomepage of
https://www.downtownmelody.com/_x/d3d3LmlscnQuYnJpcy5hYy51aw/. This is typical: FOAF groups are created by
specifying a sub-class of Agent (in fact usually this
will be a sub-class of Person), and giving criteria
for which things fall in or out of the sub-class. For this, we use the
owl:onProperty and owl:hasValue properties,
indicating the property/value pairs which must be true of matching
agents.
<!-- here we see a FOAF group described.
each foaf group may be associated with an OWL definition
specifying the class of agents that constitute the group's membership -->
<foaf:Group>
<foaf:name>ILRT staff</foaf:name>
<foaf:membershipClass>
<owl:Class rdf:about="https://www.downtownmelody.com/_x/aWxydC5leGFtcGxlLmNvbQ/groups#ILRTStaffPerson">
<rdfs:subClassOf rdf:resource="https://www.downtownmelody.com/_x/eG1sbnMuY29t/foaf/0.1/Person"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="https://www.downtownmelody.com/_x/eG1sbnMuY29t/foaf/0.1/workplaceHomepage"/>
<owl:hasValue rdf:resource="https://www.downtownmelody.com/_x/d3d3LmlscnQuYnJpcy5hYy51aw/"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
</foaf:membershipClass>
</foaf:Group>
Note that while these example OWL rules for being in the eg:ILRTStaffPerson class are
based on a Person having a particular
workplaceHomepage, this places no obligations on the authors of actual
FOAF documents to include this information. If the information is included, then
generic OWL tools may infer that some person is an eg:ILRTStaffPerson. To go the extra
step and infer that some eg:ILRTStaffPerson is a member of the group
whose name is "ILRT staff", tools will need some knowledge of the way
FOAF deals with groups. In other words, generic OWL technology gets us most of the way,
but the full Group machinery requires extra work for implimentors.
The current design names the relationship as pointing from the group, to the member. This is convenient when writing XML/RDF that encloses the members within markup that describes the group. Alternate representations of the same content are allowed in RDF, so you can write claims about the Person and the Group without having to nest either description inside the other. For (brief) example:
<foaf:Group> <foaf:member rdf:nodeID="martin"/> <!-- more about the group here --> </foaf:Group> <foaf:Person rdf:nodeID="martin"> <!-- more about martin here --> </foaf:Person>
There is a FOAF issue tracker associated with this FOAF term. A design goal is to make the most of W3C's OWL language for representing group-membership criteria, while also making it easy to leverage existing groups and datasets available online (eg. buddylists, mailing list membership lists etc). Feedback on the current design is solicited! Should we consider using SPARQL queries instead, for example?
[#] [back to top]
| Status: | stable |
|---|---|
| Properties include: | depicts thumbnail |
| Used with: | img thumbnail depiction |
| Subclass Of | Document |
The class Image is a sub-class of Document
corresponding to those documents which are images.
Digital images (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.) are examples of
Image.
[#] [back to top]
| Status: | stable |
|---|---|
| Subclass Of | Agent |
| Disjoint With: | Document Person |
The Organization class represents a kind of Agent
corresponding to social instititutions such as companies, societies etc.
This is a more 'solid' class than Group, which allows
for more ad-hoc collections of individuals. These terms, like the corresponding
natural language concepts, have some overlap, but different emphasis.
[#] [back to top]
| Status: | stable |
|---|---|
| Properties include: | plan surname geekcode pastProject lastName family_name publications currentProject familyName firstName workInfoHomepage myersBriggs schoolHomepage img workplaceHomepage knows |
| Used with: | knows |
| Subclass Of | Agent Spatial Thing |
| Disjoint With: | Project Organization |
The Person class represents people. Something is a
Person if it is a person. We don't nitpic about whether they're
alive, dead, real, or imaginary. The Person class is a sub-class of the
Agent class, since all people are considered 'agents' in FOAF.
[#] [back to top]
| Status: | testing |
|---|---|
| Properties include: | accountName accountServiceHomepage |
| Used with: | account holdsAccount |
| Subclass Of | Thing |
| Has Subclass | Online E-commerce Account Online Gaming Account Online Chat Account |
The OnlineAccount class represents the provision of some form of online
service, by some party (indicated indirectly via a accountServiceHomepage) to some Agent. The
account property of the agent is used to indicate accounts that are associated with the agent.
See OnlineChatAccount for an example. Other sub-classes include OnlineEcommerceAccount and OnlineGamingAccount.
One deployment style for this construct is to use URIs for well-known documents (or other entities) that strongly embody the account-holding relationship; for example, user profile pages on social network sites. This has the advantage of providing URIs that are likely to be easy to link with other information, but means that the instances of this class should not be considered 'accounts' in the abstract or business sense of a 'contract'.
[#] [back to top]
| Status: | testing |
|---|---|
| Subclass Of | Document |
The PersonalProfileDocument class represents those
things that are a Document, and that use RDF to
describe properties of the person who is the maker
of the document. There is just one Person described in
the document, ie.
the person who made it and who will be its
primaryTopic.
The PersonalProfileDocument class, and FOAF's
associated conventions for describing it, captures an important
deployment pattern for the FOAF vocabulary. FOAF is very often used in
public RDF documents made available through the Web. There is a
colloquial notion that these "FOAF files" are often somebody's
FOAF file. Through PersonalProfileDocument we provide
a machine-readable expression of this concept, providing a basis for
FOAF documents to make claims about their maker and topic.
When describing a PersonalProfileDocument it is
typical (and useful) to describe its associated Person
using the maker property. Anything that is a
Person and that is the maker of some
PersonalProfileDocument will be the primaryTopic of
that Document. Although this can be inferred, it is
often helpful to include this information explicitly within the
PersonalProfileDocument.
For example, here is a fragment of a personal profile document which describes its author explicitly:
<foaf:Person rdf:nodeID="p1"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="https://www.downtownmelody.com/_x/ZGFuYnJpLm9yZw/"/> <!-- etc... --> </foaf:Person> <foaf:PersonalProfileDocument rdf:about=""> <foaf:maker rdf:nodeID="p1"/> <foaf:primaryTopic rdf:nodeID="p1"/> </foaf:PersonalProfileDocument>
Note that a PersonalProfileDocument will have some
representation as RDF. Typically this will be in W3C's RDF/XML syntax,
however we leave open the possibility for the use of other notations, or
representational conventions including automated transformations from
HTML (GRDDL spec for
one such technique).
[#] [back to top]
| Status: | testing |
|---|---|
| Disjoint With: | Document Person |
The 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 the
homepage of a Project.
Further work is needed to specify the connections between this class and the FOAF properties
currentProject and pastProject.
[#] [back to top]
| Status: | unstable |
|---|---|
A LabelProperty is any RDF property with texual values that serve as labels.
Any property that is a LabelProperty is effectively a sub-property of rdfs:label. This utility
class provides an alternate means of expressing this idea, in a way that may help with OWL 2.0 DL compatibility.
[#] [back to top]
| Status: | unstable |
|---|---|
| Subclass Of | Online Account |
A OnlineChatAccount is a OnlineAccount devoted to
chat / instant messaging. The account may offer other services too; FOAF's
sub-classes of OnlineAccount are not mutually disjoint.
This is a generalization of the FOAF Chat ID properties,
jabberID, aimChatID,
skypeID, msnChatID, icqChatID and
yahooChatID.
Unlike those simple properties, 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:account>
<foaf:OnlineAccount>
<rdf:type rdf:resource="https://www.downtownmelody.com/_x/eG1sbnMuY29t/foaf/0.1/OnlineChatAccount"/>
<foaf:accountServiceHomepage
rdf:resource="https://www.downtownmelody.com/_x/d3d3LmZyZWVub2RlLm5ldA/"/>
<foaf:accountName>danbri</foaf:accountName>
</foaf:OnlineAccount>
</foaf:account>
</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 the mbox /
mbox_sha1sum mapping).
In addition to the generic OnlineAccount and
OnlineChatAccount mechanisms,
FOAF also provides several convenience chat ID properties
(jabberID, aimChatID, icqChatID,
msnChatID,yahooChatID, skypeID).
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 of
Jabber, AIM, MSN, ICQ, Yahoo! and MSN chat
accounts. This has been done for skypeID. This requires us to
identify an appropriate accountServiceHomepage for each. If we
wanted to make the OnlineAccount mechanism even more generic, we could
invent a relationship that holds between a OnlineAccount instance and a
convenience property. To continue the example above, we could describe how Freenode could define a property 'fn:freenodeChatID'
corresponding to Freenode online accounts.
[#] [back to top]
| Status: | unstable |
|---|---|
| Subclass Of | Online Account |
A OnlineEcommerceAccount is a OnlineAccount devoted to
buying and/or selling of goods, services etc. Examples include Amazon, eBay, PayPal, thinkgeek, etc.
[#] [back to top]
| Status: | unstable |
|---|---|
| Subclass Of | Online Account |
A OnlineGamingAccount is a OnlineAccount devoted to
online gaming.
Examples might include EverQuest, Xbox live, Neverwinter Nights, etc., as well as older text-based systems (MOOs, MUDs and suchlike).
[#] [back to top]
| Status: | stable | |
|---|---|---|
| Domain: | having this property implies being a Thing | |
| Range: | every value of this property is a Document | |
| Inverse Functional Property | ||
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.
[#] [back to top]
| Status: | stable | |
|---|---|---|
| Domain: | having this property implies being a Thing | |
| Range: | every value of this property is a Document | |
| Inverse Functional Property | ||
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).
[#] [back to top]
| Status: | stable |
|---|---|
| Domain: | having this property implies being a Person |
| Range: | every value of this property is a Person |
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...
[#] [back to top]