Copyright © 2000-2014 Dan Brickley and Libby Miller
This work is licensed under aCreative Commons Attribution License. This copyright applies to theFOAF Vocabulary Specification and accompanying documentation in RDF. Regarding underlying technology, FOAF uses W3C'sRDF 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, andinformation 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 tochange. 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 theFOAF 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 theRDFS/OWL machine-readable FOAF ontology with a set ofper-term documents. Future versions may incorporatemultilingual translations of the term definitions. An RDF/XML encoding of the specification is available bydirect link or by HTTPcontent negotiation from thenamespace 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 listfoaf-dev@lists.foaf-project.org;public archives are available. A historical backlog of known technical issues is acknowledged, and available for discussion on theFOAF 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 theFOAF 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 thechanges 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 ofthings and links, which we callproperties. The types of the things we talk about in FOAF are calledclasses.FOAF is therefore defined as a dictionary of terms, each of which is either aclass or aproperty. 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 ofall 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="http://xmlns.com/foaf/0.1/"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="http://danbri.org/" /> <foaf:openid rdf:resource="http://danbri.org/" /> <foaf:img rdf:resource="/images/me.jpg" /></foaf:Person>
This brief example introduces the basics of FOAF. It basically says, "there is afoaf:Person with afoaf:name property of 'Dan Brickley'; this person stands infoaf:homepage andfoaf:openid relationship to a thing called http://danbri.org/ and afoaf: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, andinformation 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 decentralisedSemantic 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 onSPARQL provides us with a rich query language for consulting databases of FOAF data, while theSKOS 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 theGRDDL andRDFa efforts for more detail. The Semantic Web provides us with anarchitecture for collaboration, allowing complex technical challenges to be shared by a loosely-coordinated community of developers.
The FOAF project is based around the use ofmachine 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 aLinked 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 asfoaf:Person
,foaf:Document
,foaf:Image
, alongside some handy properties of those things, such asfoaf: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 isfoaf:depiction
. This relates something (eg. afoaf:Person
) to afoaf: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 thisFOAF 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 FOAFwith image metadata is also available.
Theco-depiction experiment shows a fun use of the vocabulary. To create a FOAF document, you can use Leigh Dodd'sFOAF-a-matic javascript tool. For more information on FOAF and related projects, see theFOAF 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 thealt.folklore.urban archive orsnopes.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 FOAFvocabulary as specified in this document is not a standard in the sense ofISO Standardisation, or that associated withW3CProcess.
FOAF depends heavily on W3C's standards work, specifically on XML, XML Namespaces, RDF, and OWL. All FOAFdocuments must be well-formed RDF documents. The FOAF vocabulary, by contrast, is managed more in the style of anOpen Source orFree Software project than as an industry standardarisation effort (eg. seeJabber JEPs).
This specification contributes a vocabulary, "FOAF", to the Semantic Web, specifying it using W3C'sResource 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 thatSemantic Web applications can use those terms in a variety of RDF-compatible document formats and applications.
This document presents FOAF as aSemantic Web vocabulary orOntology. 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 '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 thatwe 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. theDublin 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. usingfoaf-a-matic) you can make it easier for tools to find your FOAF by putting markup in thehead
of your HTML homepage. It doesn't really matter what filename you choose for your FOAF document, althoughfoaf.rdf
is a common choice. The linking markup is as follows:
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://example.com/~you/foaf.rdf"/>
...although of course change theURL to point to your own FOAF document. See also: more onFOAF autodiscovery and services that make use of it.
FOAF introduces the following classes and properties. A machine-friendly version is also available inRDF/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: | genderyahooChatIDaccountbirthdayicqChatIDaimChatIDjabberIDmademboxinteresttipjarskypeIDtopic_interestagembox_sha1sumstatusmsnChatIDopenidholdsAccountweblog |
Used with: | makermember |
Has Subclass | GroupPersonOrganization |
TheAgent
class is the class of agents; things that do stuff. A well known sub-class isPerson
, representing people. Other kinds of agents includeOrganization
andGroup
.
TheAgent
class is useful in a few places in FOAF wherePerson
would have been overly specific. For example, the IM chat ID properties such asjabberID
are typically associated with people, but sometimes belong to software bots.
[#] [back to top]
Status: | stable |
---|---|
Properties include: | topicprimaryTopicsha1 |
Used with: | workInfoHomepageworkplaceHomepagepageaccountServiceHomepageopenidtipjarschoolHomepagepublicationsisPrimaryTopicOfinteresthomepageweblog |
Has Subclass | ImagePersonalProfileDocument |
Disjoint With: | ProjectOrganization |
TheDocument
class represents those things which are, broadly conceived, 'documents'.
TheImage
class is a sub-class ofDocument
, 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 (seesha1
for related issues).
[#] [back to top]
Status: | stable |
---|---|
Properties include: | member |
Subclass Of | Agent |
TheGroup
class represents a collection of individual agents (and may itself play the role of aAgent
, 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 ahomepage
,name
, mailing list etc.).
While aGroup
has the characteristics of aAgent
, it is also associated with a number of otherAgent
s (typically people) who constitute theGroup
. FOAF provides a mechanism, themembershipClass
property, which relates aGroup
to a sub-class of the classAgent
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, theGroup
mechanism for categorising them into groups also becomes more powerful.
While the formal description of membership criteria for aGroup
maybe complex, the basic mechanism for saying that someone is in aGroup
isvery simple. We simply use amember
property of theGroup
to indicate the agents that are members of the group. For example:
<foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:member> <foaf:Person> <foaf:name>Martin Poulter</foaf:name> <foaf:homepage rdf:resource="http://www.ilrt.bris.ac.uk/aboutus/staff/staffprofile/?search=plmlp"/> <foaf:workplaceHomepage rdf:resource="http://www.ilrt.bris.ac.uk/"/> </foaf:Person> </foaf:member></foaf:Group>
Behind the scenes, further RDF statements can be used to express the rules for being a member of this group. End-users of FOAF need not pay attention to these details.
Here is an example. We define aGroup
representing those people who are ILRT staff members (ILRT is a department at the University of Bristol). ThemembershipClass
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 aPerson
and which have aworkplaceHomepage
of http://www.ilrt.bris.ac.uk/. This is typical: FOAF groups are created by specifying a sub-class ofAgent
(in fact usually this will be a sub-class ofPerson
), and giving criteria for which things fall in or out of the sub-class. For this, we use theowl:onProperty
andowl:hasValue
properties, indicating the property/value pairs which must be true of matching agents.
<!-- here we see a FOAF group described. each foaf group may be associated with an OWL definition specifying the class of agents that constitute the group's membership --><foaf:Group> <foaf:name>ILRT staff</foaf:name> <foaf:membershipClass> <owl:Class rdf:about="http://ilrt.example.com/groups#ILRTStaffPerson"> <rdfs:subClassOf rdf:resource="http://xmlns.com/foaf/0.1/Person"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/workplaceHomepage"/> <owl:hasValue rdf:resource="http://www.ilrt.bris.ac.uk/"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> </foaf:membershipClass></foaf:Group>
Note that while these example OWL rules for being in the eg:ILRTStaffPerson class are based on aPerson
having a particularworkplaceHomepage
, this places no obligations on the authors of actual FOAF documents to include this information. If the informationis included, then generic OWL tools may infer that some person is an eg:ILRTStaffPerson. To go the extra step and infer that some eg:ILRTStaffPerson is amember
of the group whosename
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 fullGroup
machinery requires extra work for implimentors.
The current design names the relationship as pointingfrom the group, to the member. This is convenient when writing XML/RDF that encloses the members within markup that describes the group. Alternate representations of the same content are allowed in RDF, so you can write claims about the Person and the Group without having to nest either description inside the other. For (brief) example:
<foaf:Group> <foaf:member rdf:nodeID="martin"/> <!-- more about the group here --></foaf:Group><foaf:Person rdf:nodeID="martin"> <!-- more about martin here --></foaf:Person>
There is a FOAFissue tracker associated with this FOAF term. A design goal is to make the most of W3C'sOWL language for representing group-membership criteria, while also making it easy to leverage existing groups and datasets available online (eg. buddylists, mailing list membership lists etc). Feedback on the current design is solicited! Should we consider using SPARQL queries instead, for example?
[#] [back to top]
Status: | stable |
---|---|
Properties include: | depictsthumbnail |
Used with: | imgthumbnaildepiction |
Subclass Of | Document |
The classImage
is a sub-class ofDocument
corresponding to those documents which are images.
Digital images (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.) are examples ofImage
.
[#] [back to top]
Status: | stable |
---|---|
Subclass Of | Agent |
Disjoint With: | DocumentPerson |
TheOrganization
class represents a kind ofAgent
corresponding to social instititutions such as companies, societies etc.
This is a more 'solid' class thanGroup
, which allows for more ad-hoc collections of individuals. These terms, like the correspondingnatural language concepts, have some overlap, but different emphasis.
[#] [back to top]
Status: | stable |
---|---|
Properties include: | plansurnamegeekcodepastProjectlastNamefamily_namepublicationscurrentProjectfamilyNamefirstNameworkInfoHomepagemyersBriggsschoolHomepageimgworkplaceHomepageknows |
Used with: | knows |
Subclass Of | AgentSpatial Thing |
Disjoint With: | ProjectOrganization |
ThePerson
class represents people. Something is aPerson
if it is a person. We don't nitpic about whether they're alive, dead, real, or imaginary. ThePerson
class is a sub-class of theAgent
class, since all people are considered 'agents' in FOAF.
[#] [back to top]
Status: | testing |
---|---|
Properties include: | accountNameaccountServiceHomepage |
Used with: | accountholdsAccount |
Subclass Of | Thing |
Has Subclass | Online E-commerce AccountOnline Gaming AccountOnline Chat Account |
TheOnlineAccount
class represents the provision of some form of online service, by some party (indicated indirectly via aaccountServiceHomepage
) to someAgent
. Theaccount
property of the agent is used to indicate accounts that are associated with the agent.
SeeOnlineChatAccount
for an example. Other sub-classes includeOnlineEcommerceAccount
andOnlineGamingAccount
.
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 |
ThePersonalProfileDocument
class represents thosethings that are aDocument
, and that use RDF todescribe properties of the person who is themaker
of the document. There is just onePerson
described inthe document, ie.the person whomade
it and who will be itsprimaryTopic
.
ThePersonalProfileDocument
class, and FOAF'sassociated conventions for describing it, captures an importantdeployment pattern for the FOAF vocabulary. FOAF is very often used inpublic RDF documents made available through the Web. There is acolloquial notion that these "FOAF files" are oftensomebody'sFOAF file. ThroughPersonalProfileDocument
we providea machine-readable expression of this concept, providing a basis for FOAF documents to make claims about their maker and topic.
When describing aPersonalProfileDocument
it istypical (and useful) to describe its associatedPerson
using themaker
property. Anything that is aPerson
and that is themaker
of somePersonalProfileDocument
will be theprimaryTopic
ofthatDocument
. Although this can be inferred, it isoften helpful to include this information explicitly within thePersonalProfileDocument
.
For example, here is a fragment of a personal profile document whichdescribes its author explicitly:
<foaf:Person rdf:nodeID="p1"> <foaf:name>Dan Brickley</foaf:name> <foaf:homepage rdf:resource="http://danbri.org/"/> <!-- etc... --></foaf:Person><foaf:PersonalProfileDocument rdf:about=""> <foaf:maker rdf:nodeID="p1"/> <foaf:primaryTopic rdf:nodeID="p1"/></foaf:PersonalProfileDocument>
Note that aPersonalProfileDocument
will have somerepresentation as RDF. Typically this will be in W3C's RDF/XML syntax,however we leave open the possibility for the use of other notations, orrepresentational conventions including automated transformations fromHTML (GRDDL spec forone such technique).
[#] [back to top]
Status: | testing |
---|---|
Disjoint With: | DocumentPerson |
TheProject
class represents the class of things that are 'projects'. These may be formal or informal, collective or individual. It is often useful to indicate thehomepage
of aProject
.
Further work is needed to specify the connections between this class and the FOAF propertiescurrentProject
andpastProject
.
[#] [back to top]
Status: | unstable |
---|---|
ALabelProperty
is any RDF property with texual values that serve as labels.
Any property that is aLabelProperty
is effectively a sub-property of rdfs:label. This utilityclass 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 |
AOnlineChatAccount
is aOnlineAccount
devoted to chat / instant messaging. The account may offer other services too; FOAF's sub-classes ofOnlineAccount
are not mutually disjoint.
This is a generalization of the FOAF Chat ID properties,jabberID
,aimChatID
,skypeID
,msnChatID
,icqChatID
andyahooChatID
.
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="http://xmlns.com/foaf/0.1/OnlineChatAccount"/> <foaf:accountServiceHomepage rdf:resource="http://www.freenode.net/"/> <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 thembox
/mbox_sha1sum
mapping).
In addition to the genericOnlineAccount
andOnlineChatAccount
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 ofJabber,AIM,MSN,ICQ,Yahoo! andMSN chat accounts. This has been done forskypeID
. This requires us to identify an appropriateaccountServiceHomepage
for each. If we wanted to make theOnlineAccount
mechanism even more generic, we could invent a relationship that holds between aOnlineAccount
instance and a convenience property. To continue the example above, we could describe howFreenode could define a property 'fn:freenodeChatID' corresponding to Freenode online accounts.
[#] [back to top]
Status: | unstable |
---|---|
Subclass Of | Online Account |
AOnlineEcommerceAccount
is aOnlineAccount
devoted to buying and/or selling of goods, services etc. Examples includeAmazon,eBay,PayPal,thinkgeek, etc.
[#] [back to top]
Status: | unstable |
---|---|
Subclass Of | Online Account |
AOnlineGamingAccount
is aOnlineAccount
devoted to online gaming.
Examples might includeEverQuest,Xbox live,Neverwinter Nights, etc., as well as older text-based systems (MOOs, MUDs and suchlike).
[#] [back to top]
Status: | stable | |
---|---|---|
Domain: | having this property implies being aThing | |
Range: | every value of this property is aDocument | |
Inverse Functional Property |
Thehomepage
property relates something to a homepage about it.
Many kinds of things have homepages. FOAF allows a thing to have multiple homepages, but constrainshomepage
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 atopic
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.
Thehomepage
property is a sub-property of the more generalpage
property for relating a thing to a page about that thing. See alsotopic
, the inverse of thepage
property.
[#] [back to top]
Status: | stable | |
---|---|---|
Domain: | having this property implies being aThing | |
Range: | every value of this property is aDocument | |
Inverse Functional Property |
TheisPrimaryTopicOf
property relates something to a document that is mainly about it.
TheisPrimaryTopicOf
property isinverse functional: forany document that is the value of this property, there is at most one thing in the worldthat is the primary topic of that document. This is useful, as it allows for data merging, as described in the documentation for its inverse,primaryTopic
.
page
is a super-property ofisPrimaryTopicOf
. The change of terminology between the two property names reflects the utility of 'primaryTopic' and its inverse when identifying things. Anything that has anisPrimaryTopicOf
relation to some document X, also has apage
relationship to it.
Note thathomepage
, is a sub-property of bothpage
andisPrimaryTopicOf
. The awkwardly namedisPrimaryTopicOf
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 aPerson |
Range: | every value of this property is aPerson |
Theknows
property relates aPerson
to anotherPerson
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 someoneknows
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. Aknows
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...).
Sinceknows
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 eachweblog
that wasmade
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 thanknows
to relate people to people. The original FOAF design included two of these ('knowsWell','friend') which we removed because they were somewhatawkward to actually use, bringing an inappopriate air of precision to an intrinsically vague concept. Other extensions have been proposed, including Eric Vitiello'sRelationship module for FOAF.
In addition to using more specialised inter-personal relationship types (eg rel:acquaintanceOf etc) it is often just as good to use RDF descriptions of the states of affairs which imply particular kinds of relationship. So for example, two people who have the same value for theirworkplaceHomepage
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 aDocument
that has two people listed as itsmaker
s, 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 ofknows
is, alongside therdfs:seeAlso
property, to connect FOAF files together. Taken alone, a FOAF file is somewhat dull. But linked in with 1000s of other FOAF files it becomes more interesting, with each FOAF file saying a little more about people, places, documents, things... By mentioning other people (viaknows
or other relationships), and by providing anrdfs:seeAlso
link to their FOAF file, you can make it easy for FOAF indexing tools ('scutters') to find your FOAF and the FOAF of the people you've mentioned. And the FOAF of the people they mention, and so on. This makes it possible to build FOAF aggregators without the need for a centrally managed directory of FOAF files...
[#] [back to top]
Status: | stable |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aThing |
Themade
property relates aAgent
to somethingmade
by it. As such it is an inverse of themaker
property, which relates a thing to something that made it. Seemade
for more details on the relationship between these FOAF terms and related Dublin Core vocabulary.
[#] [back to top]
Status: | stable |
---|---|
Domain: | having this property implies being aThing |
Range: | every value of this property is aAgent |
Themaker
property relates something to aAgent
thatmade
it. As such it is an inverse of themade
property.
Thename
(or otherrdfs:label
) of themaker
of something can be described as thedc:creator
of that thing.
For example, if the thing named by the URI http://danbri.org/ has amaker
that is aPerson
whosename
is 'Dan Brickley', we can conclude that http://danbri.org/ has adc:creator
of 'Dan Brickley'.
FOAF descriptions are encouraged to usedc:creator
only for simple textual names, and to usemaker
to indicate creators, rather than risk confusing creators with their names. This follows most Dublin Core usage. SeeUsingDublinCoreCreator for details.
[#] [back to top]
Status: | stable | |
---|---|---|
Domain: | having this property implies being aAgent | |
Range: | every value of this property is aThing | |
Inverse Functional Property |
Thembox
property is a relationship between the owner of a mailbox and a mailbox. These are typically identified using the mailto: URI scheme (seeRFC 2368).
Note that there are many mailboxes (eg. shared ones) which are not thembox
of anyone. Furthermore, a person can have multiplembox
properties.
In FOAF, we often seembox
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 thembox_sha1sum
mechanism, which is a relationship between a person and the value you get from passing a mailbox URI to the SHA1 mathematical function.
[#] [back to top]
Status: | stable |
---|---|
Domain: | having this property implies being aGroup |
Range: | every value of this property is aAgent |
Themember
property relates aGroup
to aAgent
that is a member of that group.
SeeGroup
for details and examples.
[#] [back to top]
Status: | stable |
---|---|
Domain: | having this property implies being aThing |
Range: | every value of this property is aDocument |
Thepage
property relates a thing to a document about that thing.
As such it is an inverse of thetopic
property, which relates a document to a thing that the document is about.
[#] [back to top]
Status: | stable | |
---|---|---|
Domain: | having this property implies being aDocument | |
Range: | every value of this property is aThing | |
Functional Property |
TheprimaryTopic
property relates a document to themain thing that the document is about.
TheprimaryTopic
property isfunctional: forany document it applies to, it can have at most one value. This isuseful, as it allows for data merging. In many cases it may be difficultfor third parties to determine the primary topic of a document, but ina useful number of cases (eg. descriptions of movies, restaurants,politicians, ...) it should be reasonably obvious. Documents are veryoften the most authoritative source of information about their ownprimary topics, although this cannot be guaranteed since documents cannot beassumed to be accurate, honest etc.
It is an inverse of theisPrimaryTopicOf
property, which relates a thing to a documentprimarily about that thing. The choice between these two properties is purely pragmatic. When describing documents, we useprimaryTopic
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 useisPrimaryTopicOf
. In this way, Web sites such asWikipedia orNNDB can provide indirect identification for the things they have descriptions of.
[#] [back to top]
Status: | stable | |
---|---|---|
Domain: | having this property implies being aAgent | |
Range: | every value of this property is aDocument | |
Inverse Functional Property |
Theweblog
property relates aAgent
to a weblog of that agent.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aOnline Account |
Theaccount
property relates aAgent
to anOnlineAccount
for which they are the sole account holder. SeeOnlineAccount
for usage details.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aOnline Account |
TheaccountName
property of aOnlineAccount
is a textual representation of the account name (unique ID) associated with that account.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aOnline Account |
Range: | every value of this property is aDocument |
TheaccountServiceHomepage
property indicates a relationship between aOnlineAccount
and the homepage of the supporting service provider.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
TheaimChatID
property relates aAgent
to a textual identifier ('screenname') assigned to them in the AOL Instant Messanger (AIM) system. See AOL'sAIM site for more details of AIM and AIM screennames. TheiChat tools fromApple also make use of AIM identifiers.
SeeOnlineChatAccount
(andOnlineAccount
) for amore general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aSpatial Thing |
Range: | every value of this property is aSpatial Thing |
Thebased_near
relationship relates two "spatial things"(anything that canbe somewhere), the latter typicallydescribed using the geo:lat / geo:longgeo-positioning vocabulary(SeeGeoInfo in the W3C semwebwiki for details). This allows us to say describe the typical latitute and longitude of, say, a Person (people are spatial things - they can be places) without implying that a precise location has been given.
We do not say much about what 'near' means in this context; it is a'rough and ready' concept. For a more precise treatment, seeGeoOnion vocab designdiscussions, which are aiming to produce a more sophisticated vocabulary for such purposes.
FOAF files often make use of thecontact:nearestAirport
property. Thisillustrates the distinction between FOAF documents (which may make claims usingany RDFvocabulary) and the core FOAF vocabulary defined by this specification. For further reading onthe use ofnearestAirport
seeUsingContactNearestAirport in the FOAF wiki.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aThing |
AcurrentProject
relates aPerson
to aDocument
indicating some collaborative orindividual undertaking. This relationshipindicates that thePerson
has some active role in theproject, such as development, coordination, or support.
When aPerson
is no longer involved with a project, orperhaps is inactive for some time, the relationship becomes apastProject
.
If thePerson
has stopped working on a project because ithas been completed (successfully or otherwise),pastProject
isapplicable. In general,currentProject
is used to indicatesomeone's current efforts (and implied interests, concerns etc.), whilepastProject
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. aDocument
or to instances of the classProject
, which might themselves have ahomepage
. In practice, it seems to have been used in a similar way tointerest
, referencing homepages of ongoing projects.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aThing |
Range: | every value of this property is aImage |
Thedepiction
property is a relationship between a thing and anImage
that depicts it. As such it is an inverse of thedepicts
relationship.
A common use ofdepiction
(anddepicts
) is to indicate the contents of a digital image, for example the people or objects represented in an online photo gallery.
Extensions to this basic idea include 'Co-Depiction' (social networks as evidenced in photos), as well as richer photo metadata through the mechanism of using SVG paths to indicate theregions of an image which depict some particular thing. See'Annotating Images With SVG' for tools and details.
The basic notion of 'depiction' could also be extended to deal with multimedia content (video clips, audio), or refined to deal with corner cases, such as pictures of pictures etc.
Thedepiction
property is a super-property of the more specific propertyimg
, which is used more sparingly. You stand in adepiction
relation toanyImage
that depicts you, whereasimg
is typically used to indicate a few images that are particularly representative.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aImage |
Range: | every value of this property is aThing |
Thedepicts
property is a relationship between aImage
and something that the image depicts. As such it is an inverse of thedepiction
relationship. Seedepiction
for further notes.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
ThefamilyName
property is provided (alongsidegivenName
) for use when describing parts of people's names. Although theseconcepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simplename
property.
Support is also provided for the more archaic and culturally varying terminology offirstName
andlastName
.
See theissue tracker for design discussions, status and ongoing work on rationalising the FOAFnaming machinery.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
ThefirstName
property is provided (alongsidelastName
) as a mechanism to support legacy data that cannot beeasily interpreted in terms of the (otherwise preferred)familyName
andgivenName
properties. The conceptsof 'first' and 'last' names do not work well across cultural and linguistic boundaries; however they are widely used in addressbooks and databases.
See theissue tracker for design discussions, status and ongoing work on rationalising the FOAFnaming machinery.
There is also a simplename
property.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aConcept |
Range: | every value of this property is aThing |
Thefocus
property relates a conceptualisation of something to the thing itself.Specifically, it is designed for use with W3C'sSKOS 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 (see2005 discussion for details); for example administrative and record-keeping metadata. Two schemes might have an entry for the same individual; the foaf:focus propertycan 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 caseswhen 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 ofprimaryTopic
is particularly important in FOAF as it provides an indirect mechanism for identifying things indirectly. Asimilar approach is explored by theTDB URI scheme. FOAF includes topic-oriented functionality to address itsoriginal goals of linking people to information,as well as to other people, through the use of linked information.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Functional Property |
Thegender
property relates aAgent
(typically aPerson
) 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 usegender
in any particular document or description. Values other than 'male' and 'female' may be used, but are not enumerated here. Thegender
mechanism is not intended to capture the full variety of biological, social and sexual concepts associated with the word 'gender'.
Anything that has agender
property will be some kind ofAgent
. However there are kinds ofAgent
to which the concept of gender isn't applicable (eg. aGroup
). FOAF does not currently include a class corresponding directly to "the type of thing that has a gender".At any point in time, aAgent
has at most one value forgender
. FOAF does not treatgender
as astatic property; the same individual may have different values for this property at different times.
Note that FOAF's notion of gender isn't defined biologically or anatomically - this would be tricky since we have a broad notion that applies to allAgent
s (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 theirgender
. 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, supportslying. Application authors using FOAF data should always be cautious in their presentation of unverified information, but be particularly sensitive to issues and risks surrounding sex and gender (including privacy and personal safety concerns). Designers of FOAF-based user interfaces should be careful to allow users to omitgender
when describing themselves and others, and to allow at least for values other than 'male' and 'female' as options. Users of information conveyed via FOAF (as via information conveyed through mobile phone text messages, email, Internet chat, HTML pages etc.) should be skeptical of unverified information.
[#] [back to top]
Status: | testing |
---|---|
ThegivenName
property is provided (alongsidefamilyName
) for use when describing parts of people's names. Although theseconcepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simplename
property.
Support is also provided for the more archaic and culturally varying terminology offirstName
andlastName
.
See theissue tracker for design discussions, status and ongoing work on rationalising the FOAFnaming machinery.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
TheicqChatID
property relates aAgent
to a textual identifier assigned to them in the ICQ Chat system. See theicq chat site for more details of the 'icq' service. Their "What is ICQ?" document provides a basic overview, while their "About Us page notes that ICQ has been acquired by AOL. Despite the relationship with AOL, ICQ is at the time of writing maintained as a separate identity from the AIM brand (seeaimChatID
).
SeeOnlineChatAccount
(andOnlineAccount
) for amore general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aImage |
Theimg
property relates aPerson
to aImage
that represents them. Unlike its super-propertydepiction
, we only useimg
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 generaldepiction
property (and its inverse,depicts
), theimg
property is only used with representations of people (ie. instances ofPerson
). 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 thandepiction
so we can have a useful way of picking out a reasonable image to represent someone. FOAF definesimg
as a sub-property ofdepiction
, which means that the latter relationship is implied whenever two things are related by the former.
Note thatimg
does not have any restrictions on the dimensions, colour depth, format etc of theImage
it references.
Terminology: note thatimg
is a property (ie. relationship), and thatcode:Image
is a similarly named class (ie. category, a type of thing). It might have been more helpful to callimg
'mugshot' or similar; instead it is named by analogy to the HTML IMG element.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aDocument |
Theinterest
property represents an interest of aAgent
, through indicating aDocument
whosetopic
(s) broadly characterises that interest.
For example, we might claim that a person or group has an interest in RDF by saying theystand in ainterest
relationship to theRDF home page. Loosly, such RDF would be saying"this agent is interested in the topic of this page".
Uses ofinterest
include a variety of filtering and resource discovery applications. It could be used, for example, to help find answers to questions such as "Find me members of this organisation with an interest in XML who have also contributed toCPAN)".
This approach to characterising interests is intended to compliment other mechanisms (such as the use of controlled vocabulary). It allows us to use a widely known set of unique identifiers (Web page URIs) with minimal pre-coordination. Since URIs have a controlled syntax, this makes data merging much easier than the use of free-text characterisations of interest.
Note that interest does not imply expertise, and that this FOAF term provides no support for characterising levels of interest: passing fads and lifelong quests are both examples of someone'sinterest
. Describing interests in full is a complex undertaking;interest
provides one basic component of FOAF's approach to these problems.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
ThejabberID
property relates aAgent
to a textual identifier assigned to them in theJabber messaging system. See theJabber site for more information about the Jabber protocols and tools.
Jabber, unlike several other online messaging systems, is based on an open, publically documented protocol specification, and has a variety of open source implementations. Jabber IDs can be assigned to a variety of kinds of thing, including software 'bots', chat rooms etc. For the purposes of FOAF, these are all considered to be kinds ofAgent
(ie. things thatdo stuff). The uses of Jabber go beyond simple IM chat applications. ThejabberID
property is provided as a basic hook to help support RDF description of Jabber users and services.
SeeOnlineChatAccount
(andOnlineAccount
) for amore general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
ThelastName
property is provided (alongsidefirstName
) as a mechanism to support legacy data that cannot beeasily interpreted in terms of the (otherwise preferred)familyName
andgivenName
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 theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simplename
property.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aThing | |
Range: | every value of this property is aThing | |
Inverse Functional Property |
Thelogo
property is used to indicate a graphical logo of some kind.It is probably underspecified...
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
Ambox_sha1sum
of aPerson
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 ambox
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 ambox_sha1sum
representation of it. Just as ambox
can be used as an indirect identifier for its owner, we can do the same withmbox_sha1sum
since there is only onePerson
with any particular value for that property.
Many FOAF tools usembox_sha1sum
in preference to exposing mailbox information. This is usually for privacy and SPAM-avoidance reasons. Other relevant techniques include the use of PGP encryption (seeEdd Dumbill's documentation) and the use ofFOAF-based whitelists for mail filtering.
Code examples for SHA1 in C#, Java, PHP, Perl and Python can be foundin Sam Ruby's weblog entry. Remember to include the 'mailto:' prefix, but no trailing whitespace, when computing ambox_sha1sum
property.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
ThemsnChatID
property relates aAgent
to a textual identifier assigned to them in the Microsoft online chat system originally known as 'MSN', and nowWindows Live Messenger.See theMicrosoft mesenger andWindows Live ID sites for more details.
SeeOnlineChatAccount
(andOnlineAccount
) for a more general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
ThemyersBriggs
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. ThemyersBriggs
property applies only to thePerson
class; wherever you see it, you can infer it is being applied to a person.
ThemyersBriggs
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 ofweblog
is an endorsement of soapboxes.
The values formyersBriggs
are the following 16 4-letter textual codes: ESTJ, INFP, ESFP, INTJ, ESFJ, INTP, ENFP, ISTJ, ESTP, INFJ, ENFJ, ISTP, ENTJ, ISFP, ENTP, ISFJ. If multiple of these properties are applicable, they are represented by applying multiple properties to a person.
For further reading on MBTI, see various online sources (eg.this article). There are various online sites which offer quiz-based tools for determining a person's MBTI classification. The owners of the MBTI trademark have probably not approved of these.
This FOAF property suggests some interesting uses, some of which could perhaps be used to test the claims made by proponents of the MBTI (eg. an analysis of weblog postings filtered by MBTI type). However it should be noted that MBTI FOAF descriptions are self-selecting; MBTI categories may not be uniformly appealing to the people they describe. Further, there is probably a degree of cultural specificity implicit in the assumptions made by many questionaire-based MBTI tools; the MBTI system may not make sense in cultural settings beyond those it was created for.
See alsoCory Caplinger's summary table or the RDFWeb article,FOAF Myers Briggs addition for further background and examples.
Note: Myers Briggs Type Indicator and MBTI are registered trademarks of Consulting Psychologists Press Inc. Oxford Psycholgists Press Ltd has exclusive rights to the trademark in the UK.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aThing |
Thename
of something is a simple textual string.
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 theissue tracker for status of work on this issue.
Thename
property, like all RDF properties with a range of rdfs:Literal, may be used with XMLLiteral datatyped values (multiplename
s 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.
[#] [back to top]
Status: | testing |
---|---|
Thenick
property relates aPerson
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
andicqChatID
. 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. TheOnlineAccount
term (and supporting vocabulary) are provided as a more verbose and more expressive generalisation of these properties.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Range: | every value of this property is aDocument | |
Inverse Functional Property |
Aopenid
is a property of aAgent
that associates it with a document that can be used as anindirect identifier in the manner of theOpenID "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.
Theopenid
property is "inverse functional", meaning that anything that is the foaf:openid of something, is theopenid
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
andGroup
, that allow for such scenarios to be consistent with the notion that any foaf:openid is the foaf:openid of just oneAgent
.
FOAF does not mandate any particular URI scheme for use asopenid
values. The OpenID 1.1 specification includes adelegation 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 similartechnique is used for FOAF autodiscovery in HTML. A single document can, for example, serve both as a homepage and an OpenID identity URL.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aThing |
After aPerson
is no longer involved with acurrentProject
, or has been inactive for some time, apastProject
relationship can be used. This indicates thatthePerson
was involved with the described project at onepoint.
If thePerson
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.), whilepastProject
describes what they've previously been doing.
[#] [back to top]
Status: | testing |
---|---|
Thephone
of something is a phone, typically identified using the tel: URI scheme.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Theplan
property provides a space for aPerson
to hold some arbitrary content that would appear ina traditional '.plan' file. The plan file was stored in a user's homedirectory on a UNIX machine, and displayed to people when the user wasqueried with the finger utility.
A plan file could contain anything. Typical uses included briefcomments, thoughts, or remarks on what a person had been doing lately. Planfiles were also prone to being witty or simply osbscure. Others may be morecreative, writing any number of seemingly random compositions in their planfile for people to stumble upon.
SeeHistory of the Finger Protocol by Rajiv Shah for more on this piece of Internet history. Thegeekcode
property may also be of interest.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aDocument |
Thepublications
property indicates aDocument
listing (primarily in human-readable form) some publications associated with thePerson
. Such documents are typically published alongside one'shomepage
.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aDocument |
TheschoolHomepage
property relates aPerson
to aDocument
that is thehomepage
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 ofOrganization
). The original application area forschoolHomepage
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 usingschoolHomepage
.
This very basic facility provides a basis for a low-cost, decentralised approach to classmate-reunion and suchlike. Instead of requiring a central database, we can use FOAF to express claims such as 'I studiedhere' simply by mentioning a school's homepage within FOAF files. Given the homepage of a school, it is easy for FOAF aggregators to lookup this property in search of people who attended that school.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aAgent |
Theskype
property relates aAgent
to an account name of a Skype account of theirs.
SeeOnlineChatAccount
(andOnlineAccount
) for amore general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aImage |
Range: | every value of this property is aImage |
Thethumbnail
property is a relationship between a full-sizeImage
and a smaller, representativeImage
that has been derrived from it.
It is typical in FOAF to expressimg
anddepiction
relationships in terms of the larger, 'main' (in some sense) image, rather than its thumbnail(s). Athumbnail
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 thumbnaildepicts
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.
Athumbnail
is typically small enough that it can beloaded and viewed quickly before a viewer decides to download the largerversion. They are often used in online photo gallery applications.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aDocument |
Thetipjar
property relates anAgent
to aDocument
that describes some mechanisms forpaying or otherwise rewarding that agent.
Thetipjar
property was created followingdiscussions about simple, lightweight mechanisms that could be used to encourage rewards and payment for content exchanged online. An agent'stipjar
page(s) could describe informal ("Send me apostcard!", "here's my book, music and movie wishlist") or formal(machine-readable micropayment information) information about how thatagent can be paid or rewarded. The reward is not associated with anyparticular action or content from the agent concerned. A link to a service such asPayPal is thesort of thing we might expect to find in a tipjar document.
Note that the value of atipjar
property is just adocument (which can include anchors into HTML pages). We expect, but do not currently specify, that this will evolve into a hookfor finding more machine-readable information to support payments,rewards. TheOnlineAccount
machinery is also relevant,although the information requirements for automating payments are not currently clear.
[#] [back to top]
Status: | testing |
---|---|
This property is a candidate for deprecation in favour of 'honorificPrefix' following Portable Contacts usage. See theFOAF Issue Tracker.
The approriate values fortitle
are not formally constrained, and will vary across community and context. Values such as 'Mr', 'Mrs', 'Ms', 'Dr' etc. are expected.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aDocument |
Range: | every value of this property is aThing |
Thetopic
property relates a document to a thing that the document is about.
As such it is an inverse of thepage
property, which relates a thing to a document about that thing.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aThing |
Thetopic_interest
property links aAgent
to a thing that they're interested in. Unliketopic
it is not indirected through a document, but links the thing directly.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aDocument |
TheworkInfoHomepage
of aPerson
is aDocument
that describes their work. It is generally (but not necessarily) a different document from theirhomepage
, and from anyworkplaceHomepage
(s) they may have.
The purpose of this property is to distinguish those pages you often see, which describe someone's professional role within an organisation or project. These aren't really homepages, although they share some characterstics.
[#] [back to top]
Status: | testing |
---|---|
Domain: | having this property implies being aPerson |
Range: | every value of this property is aDocument |
TheworkplaceHomepage
of aPerson
is aDocument
that is thehomepage
of aOrganization
that they work for.
By directly relating people to the homepages of their workplace, we have a simple convention that takes advantage of a set of widely known identifiers, while taking care not to confuse the things those identifiers identify (ie. organizational homepages) with the actual organizations those homepages describe.
For example, Dan Brickley works at W3C. Dan is aPerson
with ahomepage
of http://danbri.org/; W3C is aOrganization
with ahomepage
of http://www.w3.org/. This allows us to say that Dan has aworkplaceHomepage
of http://www.w3.org/.
<foaf:Person> <foaf:name>Dan Brickley</foaf:name> <foaf:workplaceHomepage rdf:resource="http://www.w3.org/"/></foaf:Person>
Note that several other FOAF properties work this way;schoolHomepage
is the most similar. In general, FOAF often indirectly identifies things via Web page identifiers where possible, since these identifiers are widely used and known. FOAF does not currently have a term for the name of the relation (eg. "workplace") that holds between aPerson
and anOrganization
that they work for.
[#] [back to top]
Status: | testing | |
---|---|---|
Domain: | having this property implies being aAgent | |
Inverse Functional Property |
TheyahooChatID
property relates aAgent
to a textual identifier assigned to them in the Yahoo online Chat system. See Yahoo's theYahoo! Chat site for more details of their service. Yahoo chat IDs are also used across several other Yahoo services, including email andYahoo! Groups.
SeeOnlineChatAccount
(andOnlineAccount
) for amore general (and verbose) mechanism for describing IM and chat accounts.
[#] [back to top]
Status: | unstable | |
---|---|---|
Domain: | having this property implies being aAgent | |
Functional Property |
Theage
property is a relationship between aAgent
and an integer string representing their age in years. See alsobirthday
.
[#] [back to top]
Status: | unstable | |
---|---|---|
Domain: | having this property implies being aAgent | |
Functional Property |
Thebirthday
property is a relationship between aAgent
and a string representing the month and day in which they were born (Gregorian calendar).SeeBirthdayIssue for details of related properties that can be used to describe such things in more flexible ways.
See alsoage
.
[#] [back to top]
Status: | unstable |
---|---|
ThemembershipClass
property relates aGroup
to an RDF class representing a sub-class ofAgent
whose instances are all the agents that are amember
of theGroup
.
SeeGroup
for details and examples.
[#] [back to top]
Status: | unstable |
---|---|
Domain: | having this property implies being aDocument |
Thesha1
property relates aDocument
to the textual form of a SHA1 hash of (some representation of) its contents.
The design for this property is neither complete nor coherent. TheDocument
class is currently used in a way that allows multiple instances at different URIs to have the 'same' contents (and hence hash). Ifsha1
is an owl:InverseFunctionalProperty, we could deduce that several such documents were the self-same thing. A more careful design is needed, which distinguishes documents in a broad sense from byte sequences.
[#] [back to top]
Status: | unstable |
---|---|
Domain: | having this property implies being aAgent |
status
is a short textual string expressing what the user is happyfor the general public (normally) to know about their current activity. mood, location, etc.
[#] [back to top]
Status: | archaic |
---|---|
ThednaChecksum
property is mostly a joke, but also a reminder that there will be lots of different identifying properties for people, some of which we might find disturbing.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aPerson |
This property is considered anarchaic spelling offamilyName
.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aThing |
Range: | every value of this property is aThing |
ThefundedBy
property relates something to something else that has provided funding for it.
This property is tentatively consideredarchaic usage, unless we hear about positive implementation experience.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aPerson |
Thegeekcode
property is used to represent a 'Geek Code' for somePerson
.
See theWikipedia entry for details of the code, which provides a somewhat frivolous and willfully obscure mechanism for characterising technical expertise, interests and habits. Thegeekcode
property is not bound to any particular version of the code.
[#] [back to top]
Status: | archaic |
---|---|
ThegivenName
property is provided (alongsidefamilyName
) for use when describing parts of people's names. Although theseconcepts do not capture the full range of personal naming styles found world-wide, they are commonly used and have some value.
There is also a simplename
property.
Support is also provided for the more archaic and culturally varying terminology offirstName
andlastName
.
See theissue tracker for design discussions, status and ongoing work on rationalising the FOAFnaming machinery.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aAgent |
Range: | every value of this property is aOnline Account |
This property is consideredarchaic usage. It is generally better to useaccount
instead.
TheholdsAccount
property relates aAgent
to anOnlineAccount
for which they are the sole account holder. SeeOnlineAccount
for usage details.
This property is equivalent to theaccount
property, which was introduced primarily to provide simpler naming for the same idea.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aPerson |
A number of naming constructs are under development to providenaming substructure; draft properties includefirstName
,givenName
, andsurname
. These are not currently stable or consistent; see theissue tracker for design discussions, status and ongoing work on rationalising the FOAF naming machinery.
There is also a simplename
property.
[#] [back to top]
Status: | archaic |
---|---|
Domain: | having this property implies being aThing |
Range: | every value of this property is aThing |
This property is consideredarchaic usage, and is not currently recommended for usage.
Thetheme
property is rarely used and under-specified. The intention was to use it to characterise interest / themes associated with projects and groups. Further work is needed to meet these goals.
[#] [back to top]
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.
Each term in FOAF is annotated with properties from theSemWeb Vocab Status Ontology
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'.
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 theW3CBasic Geo Vocabulary. It assumes use of the WGS84 referencesystem and defines properties geo:lat, geo:long and geo:alt in terms of a class geo:SpatialThing.
Thefoaf: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.
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. SeeW3C'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 formore 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 introducesome of these and discuss briefly how they relate to FOAF's approach to describing things.
The Dublin Core specification provides term definitions that focus on issues of resource discovery, document description and related concepts useful forcultural heritage and digital library applications. FOAF can be used alongside any variants of Dublin Core, but works most effectively with the most modernDublin 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.
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. Morerecent RDF representations of Wordnet now exist, however they don't map Wordnet synsets to classes, so can't be directly used here. Futureversions of this specification might restore links to some version of Wordnet in RDF.
Many terms in theSIOC vocabulary are defined with reference to FOAF. See theSIOC project for details. Future versions of this specification may provide more information here.
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 therdfweb-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'sFoafExplorer, Daniel Krech'sWeb 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'sfoaf-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 atEcademy,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 enthusedmany about hooking FOAF up to Geo and mapping data, as has Matt Biddulph byexplaining 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 documentedin Japanese andSpanish than in English, thanks to Masahide Kanzaki and Leandro Mariano Lopez (inkel) respectively. Thanks also toChris Schmidt for fixing up thespec generation tool (now a Python/Redland script), as well as for contributing numerouscool 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 wonderfulFOAF 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 upyears ago, for seeing what "hypertext flexibility" could bring...
foaf:focus
property relates a conceptualisation of something to the thing itself." We stay quiet for now on whether it is functional, inverse functional, ...foaf:givenName
andfoaf:familyName
have been changed fromfoaf:givenname
andfoaf:family_name
to make FOAF in line with usage of these terms in thePortable Contacts format. The previous versions remain in the document, marked as 'archaic'.foaf:fundedBy
andfoaf:theme
foaf:holdsAccount
has been marked as 'archaic' in favour offoaf:account