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.

Abstract

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.

Status of This Document

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.

FOAF at a glance

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.

Core -
These classes and properties form the core of FOAF. They describe characteristics of people and social groups
that are independent of time and technology; as such they can be used to describe basic information about people in
present day, historical, cultural heritage and digital library contexts. In addition to various characteristics of
people, FOAF defines classes for Project, Organization and Group as other kinds of agent. Related work: Dublin Core, SKOS, DOAP, SIOC, Org vocabulary, Bio vocabulary.

Social Web - in addition to the FOAF core terms, there are a number of terms for use when describing Internet accounts, addressbooks and other Web-based activities. Related work: Portable Contacts, W3C Social Web group.

Linked Data utilities - FOAF began as the 'RDFWeb' project, and established a widely adopted model for publishing simple factual data via a networked of linked RDF documents. FOAF remains important to the growing "Linked Data" community, while also maintaining a concern for information that is not readily summarised as simple factual data. FOAF is an attempt to use the Web to integrate factual information with information in human-oriented documents (eg. videos, books, spreadsheets, 3d models), as well as information that is still in people's heads. This history explains why FOAF includes a few 'demonstration' terms that served largely educational purposes (eg. geekcode), alongside a few technical utility terms (eg. focus, LabelProperty) that support wider information-linking efforts. The dictionary-based design of FOAF allows a certain pragmatism: we simply record here a set of terms that are useful to the Web community, while keeping an emphasis on the central idea of FOAF, which is about linking networks of information with networks of people.

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 http://danbri.org/ and a foaf:img relationship to a thing referenced by a relative URI of /images/me.jpg

1 Introduction: FOAF Basics

The Semantic Web

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 and the Semantic Web

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

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.

Background

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.

FOAF and Standards

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 W3CProcess.

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.

The FOAF Vocabulary Description

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.

Evolution and Extension of FOAF

The FOAF vocabulary is identified by the namespace URI
'http://xmlns.com/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.

FOAF Auto-Discovery: Publishing and Linking FOAF files

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:

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.

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).

Class: foaf:Group

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:

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
http://www.ilrt.bris.ac.uk/. 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.

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?

Class: foaf:Organization

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.

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.

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.

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'.

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.

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).

Class: foaf:LabelProperty

Label Property - A foaf:LabelProperty is any RDF property with texual values that serve as labels.

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.

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).

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.

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.

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).

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...

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.

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.

Property: foaf:mbox

personal mailbox - A personal mailbox, ie. an Internet mailbox associated with exactly one owner, the first owner of this mailbox. This is a 'static inverse functional property', in that there is (across time and change) at most one individual that ever has any particular value for 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.

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.

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.

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.

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.

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 anyImage that depicts
you, whereas img is typically used to indicate a few images that are
particularly representative.

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.

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.

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.

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.

Property: foaf:givenName

Given name - The given name of some person.

Status:

testing

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.

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).

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.

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.

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.

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.

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.

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.

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.

Property: foaf:name

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

<foaf:name xml:lang="en">Dan Brickley</foaf:name>

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Property: foaf:geekcode

The geekcode property is used to represent a 'Geek Code' for some
Person.

See the Wikipedia entry for
details of the code, which provides a somewhat frivolous and willfully obscure mechanism for
characterising technical expertise, interests and habits. The geekcode
property is not bound to any particular version of the code.

Property: foaf:givenname

Given name - The given name of some person.

Status:

archaic

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.

Property: foaf:surname

A number of naming constructs are under development to provide
naming substructure; draft properties include firstName,
givenName, and surname. These are not currently
stable or consistent; see the issue
tracker for design discussions, status and ongoing work on rationalising the FOAF
naming machinery.

External Vocabulary References

The description of the terms in the FOAF 'dictionary' often make reference to classes and properties elsewhere. This section of the FOAF specification provides a placeholder reference for any FOAF mention of externally defined terms. For example, sometimes we might say that FOAF property has a domain or range of an externally defined class, or that a FOAF class is a sub-class of an external class, or 'disjoint with' such a class (ie. has no common members). Such claims help fix the intended meaning of FOAF terms in relationship to other 'peer' vocabularies.

Status Vocabulary

This was created as an experiment in documenting FOAF's term-centric versioning model, in which a common fixed namespace URI is used, while term definitions slowly and independently evolve through different stability levels. This contrasts with other approaches to versioning which attach versioning information to larger sets of terms.

Note that this mechanism is itself somewhat experimental and evolvin. The definitions of 'stable', 'unstable', 'archaic' and 'testing' cannot be defined as global absolutes, but only in relationship to the practices, expectations and social structures around some vocabulary. For their use in FOAF, future versions of this specification could usefully offer more detail about what to expect from a term labelled 'stable'.

vs:term_status

The vs:term_status property indicates the status of a vocabulary term, one of 'stable','unstable','testing' or 'archaic'.

W3C Basic Geo (WGS84 lat/long) Vocabulary

Members of the FOAF and W3C Semantic Web Interest Group communities collaborated in 2003 to create a very simple vocabulary that described
points in geographic space. This is the W3CBasic Geo Vocabulary. It assumes use of the WGS84 reference
system and defines properties geo:lat, geo:long and geo:alt in terms of a class geo:SpatialThing.

The foaf:based_near property relates a spatial thing (typically a foaf:Agent of some kind) to another spatial thing,
which can be described using geo:lat, geo:long etc.

RDF Vocabulary Description - core concepts

The FOAF dictionary of terms is defined using a family of W3C standards: RDF, RDF Schema and OWL. These share a data model and general approach, and
provide for increasing levels of expressivity. Here we introduce the core OWL and RDF/S terms used directly in the machine-readable description of FOAF. See
W3C's site for the latest and most authoritative OWL and RDF specifications.

FOAF is based on the exchange of free-form descriptions that are structured in terms of things having properties, where the value of each property is
expressed as either textually (eg. a name or number), or by reference to another thing. FOAF (as an application of RDF) uses URI identifiers wherever
possible to talk about things of interest, whether they are Web pages, classes of thing, properties of things, or even people. See the W3C Web Architecture specification for more background on URIs.

From core RDF, FOAF takes the notion that we are talking about things, and they fall into categories; we call these 'classes'. The core machinery we
use from the RDF Schema and OWL technologies simply give us some built-in terminology for talking about things, classes and properties. Here we introduce
some of these and discuss briefly how they relate to FOAF's approach to describing things.

owl:Thing

OWL introduces the class 'Thing' as a name for the universal class of all things. This is sometimes useful when
we want to express universality of property use, eg. that anything can be the value of foaf:depicts.

rdf:Property

RDF has a built-in class called rdf:Property. This is the class of all things like foaf:homepage or dc:creator which define named kinds of
relationship between pairs of things, or between things and textually-expressed information.

owl:DatatypeProperty

The OWL specifications give a name for those properties whose values are textually-expressed: "DataTypeProperty". RDF allows these to be either plain literal values (these can also carry an indicator of their language, via xml:lang), or else "data-typed", which means they are marked with a URI indicating
their type (but no language tagging).

owl:ObjectProperty

ObjectProperty is OWL's name for those properties which are not textually-expressed; instead, they are used when mentioning or referring to
some other thing. OWL encourages vocabularies to avoid using a single named property in both 'ObjectProperty' and 'DataTypeProperty' styles. However
earlier usage, notably in the Dublin Core community, does just this. Each FOAF property is either an Object Property or DataType Property.

rdf:type

One of the most commonly used built-in relationships in RDF is 'type'. RDF type relates something to a class that it is in.

rdfs:subClassOf

RDFS gives a name for the relationship between some specific class and its more general superclass: 'subClassOf'. It would have perhaps been
simpler if this was called 'superProperty'. So for example we say that foaf:Person has an rdfs:subClassOf property whose value is foaf:Agent.

rdfs:Class

RDFS gives the name 'Class' to those things that represent classes of thing, ie. which are values of rdf:type for their members. The
OWL language also (for technical reasons) defines owl:Class for essentially the same notion. OWL also includes powerful machinery for defining the
membership rules for classes. This is not heavily used in FOAF, beyond the experimental mechanisms associated with foaf:Group.

rdfs:subClassOf

RDFS gives a name for the relationship between some particular class and its more general superclass: 'subClassOf'. It would have perhaps been
simpler if this was called 'superProperty'. So for example we say that foaf:Person has a subPropertyOf property whose value is foaf:Agent.

rdfs:subPropertyOf

Similar to subClassOf but for hierarchies of properties, we can use rdfs:subPropertyOf to point to a more general super-property, for example
we say foaf:aimChatID rdfs:subPropertyOf foaf:nick.

rdfs:domain

The RDFS specification introduced the notion of a property's domain. This is a way of saying, for some property, something about the
kind of classes it is used with. If you know the domain or domains for some property, you know that whenever you see that property applied to something,
then that thing ought to be a member of those classes. Note that this does not mean that every description using the property is compelled to mention
all those classes, just that the meaning of the property implies also the type of the thing the property is applied to.

rdfs:range

RDFS also defines a property of properties called 'range'; this works just like rdfs:domain, except for the values of a property. If you know the
range of some property, you know what kinds of thing are reasonable values for it.

owl:FunctionalProperty

OWL provides even more useful information about properties, such as the ability to say that a property is 'functional'. This means simply that
for any particular thing, you can expect at most one value for that property. It is simplest to think of this as
contextualised to any given time; although OWL doesn't talk about time explicitly. So we might say that 'age' is functional, even though a series of
FOAF documents might be published, each truthfully giving different values for my 'age' which made sense in their original context. At the time of
writing, the only W3C technology that can take a larger perspective on such different perspectives / views (or 'graphs') is SPARQL. If you have two
different values for a given functional property, you know you have a problem; perhaps one is out-of-date, for example. Or perhaps they only differ in
trivial detail (eg. date syntax, whitespace).

owl:InverseFunctionalProperty

OWL also gives a name for properties where common values tell us something about the identity of the thing having the property. On the Web this
can be very useful. OWL tells us that two descriptions are of the same thing, if they include truthful mention of some 'inverse functional property'
that has the same value. The classic FOAF example could be two mentions of a person having some particular foaf:homepage. This OWL construct is very useful for reasoning about identity and merging scattered and partial descriptions.

owl:inverseOf

OWL provides a property 'inverseOf' that holds between inverse properties; for example, any two things related by foaf:maker are related in
the reverse direction by foaf:made.

owl:disjointWith

OWL also lets us indicate that two classes have no common members. This can be useful for clarifying modelling assumptions in a language-neutral manner; eg. we might ask whether anything can be both a foaf:Group and a foaf:Organization simultaneously.

owl:sameAs

OWL provides a term for talking about identity in the sense of "being one and the same thing as". Many FOAF constructs imply
that two seemingly different things are in fact mentions of the self-same real world entity; this can be written out explicitly
using owl:sameAs. For example, if two FOAF descriptions give URI identifiers http://example.com/foo#person1 and http://example.org/bar#person2 in two person-descriptions, but ascribe the same homepage URI, we can conclude that person1 is owl:sameAs person2 (and vice-versa). This construct provides a powerful mechanism for decentralised, linked data.

skos:Concept

W3C provides a rich framework for describing linked topics, SKOS. FOAF defines a
small extension to SKOS called foaf:focus designed to link conceptualisations of entities to more
linked data (eg. in FOAF) about the specific thing a SKOS "Concept" is about. 'Concept' is SKOS's fundamental class, and
corresponds to abstractions common in library and cultural heritage information systems, including thesauri and subject indexing schemes.

Dublin Core terms

The Dublin Core specification provides term definitions that focus on issues of resource discovery, document description and related concepts useful for
cultural heritage and digital library applications. FOAF can be used alongside any variants of Dublin Core, but works most effectively with the most
modern Dublin Core terms namespace. Note that here we use the prefix 'dct:' to stand for the DC Terms namespace; however
it is not unusual to see 'dc' also used.

Dublin Core's notion of Agent is much like FOAF's; Dublin Core says "A resource that acts or has the power to act.", we say "things that do stuff". As nobody has
provided a counter-example of something fitting one definition but not the other, we say here that foaf:Agent stands in an 'equivalent class' relationship to dct:Agent (and vice-versa).

The notion of 'creator' in the latest versions of Dublin Core matches FOAF's notion of 'maker'; based on their definitions,
every pair of things that are related by one of those properties are also related by the other. We express this by saying that
these properties stand in an 'equivalent property' relationship' to one another.

Wordnet terms

Earlier versions of this specification used an experimental companion namespace produced from the lexical database Wordnet (v1.6). This is
currently offline, and corresponding sub-class relationships have been ommited from the FOAF documentation. More recent RDF representations of Wordnet now exist, however they don't map Wordnet synsets to classes, so can't be directly used here. Future
versions of this specification might restore links to some version of Wordnet in RDF.

SIOC terms

Many terms in the SIOC vocabulary are defined with reference to FOAF. See the SIOC project for details. Future versions of this specification may provide more information here.

Acknowledgments

There are far too many people who have contributed to the FOAF
project to name everyone in this early-release of the new
improved spec. FOAF wouldn't be such a fun project or be as
widely known as it is today without the efforts, enthusiasm and
intelligence of the folks who have contributed via the rdfweb-dev list,
#foaf IRC channel, and wiki.

That said, a few milestones in FOAF's history should be
mentioned. We owe particular thanks to Edd Dumbill for his IBM
developerWorks articles (which attracted the affections of the
Weblogging crowd) and for his Foafbot application whose evolution
those articles have tracked. Also Morten Frederiksen's FoafExplorer,
Daniel Krech's Web View
aggregator, Jim Ley and Liz Turner's work on FOAFNaut, which alongside
FOAFbot have been instrumental in showing how FOAF data can be
collected and used. Meanwhile Leigh Dodd's foaf-a-matic
has been the data creation tool that has been most people's
gateway to FOAFdom. FOAF also owes a lot to the folks at Ecademy, TypePad and elsewhere for showing
how end users can share FOAF self-descriptions on the Web without
ever seeing a line of XML syntax. Jo Walsh has
enthused many
about hooking FOAF up to Geo and mapping data, as has Matt
Biddulph by explaining the
workings of his FOAF harvesting and image metadata tools. FOAF
has also benefited greatly from documentation contributed in
non-English languages, many thanks to all contributors of
translations (foaf-a-matic and other docs). FOAF is now arguably
better documented in Japanese and
Spanish
than in English, thanks to Masahide Kanzaki and Leandro Mariano
Lopez (inkel) respectively. Thanks also to Chris Schmidt for fixing up
the spec generation tool (now a
Python/Redland script), as well as for contributing numerous
cool hacks to the FOAF
community. To Richard Cyganiak and others in IRC for (amongst much else) help debugging
Apache configurations. To Ian Davis for his wonderful FOAF Logo. And last but not least, Marc Canter is in a class of his own. Thanks all,
and to those who aren't listed here yet, but who made a difference...

This brief survey only scratches the surface of a growing body
of work. Sincere thanks to all who have contributed tools,
documentation, brain cells and enthusiasm to this project. We
should also mention that FOAF would not be possible without the
collaborative and opensource efforts of the RDF developer
community, both in terms of idea sharing (#swig etc) and freely
available tools (Jena, Redland, RDFlib, Cwm, Sesame, 3store
etc).

Thanks also to TimBL, who dreamed most of this up years ago, for seeing what "hypertext flexibility" could bring...

editorial: Reworded copyright statement to clarify intent; we used to say "and does not apply to FOAF data formats, vocabulary
terms, or technology.", which gave impression we were holding stuff back. Rather, this is just our understanding of copyright. The
underlying technology part is completely supplied by W3C's specifications.