FOAF contains a good few inverse functional properties (IFPs) which can be used in two ways:

1. The values of the properties can be used directly themselves when useful, for example the foaf:mbox property can be used to obtain an email address to contact someone with.
2. The values can be used when combining information about an individual from different sources. If there are two descriptions of a resource and each resource has the same value for a given IFP then those resources are in fact one and the same, and they can be merged.

A consequence of this is that the meaning of, say, foaf:weblog is not merely:

A weblog of some thing (whether person, group, company etc.).

Rather the meaning is a weblog of some thing, that is not shared by any other thing. This is not true of all weblogs (including some of the best). Similarly there are still quite a few people who have an email mailbox they share with someone else (generally their partner) that they use as their “main” mailbox. Even in the case of foaf:homepage, while arguably foaf_page would serve adequately for a page that was about someone, but not exclusively about them, there are people who have a page that is personal enough and directly relevant enough that it could be considered a personal homepage, and yet which isn’t solely theirs. foaf:homepage has been found to be particularly unreliable as an IFP in FOAF data mined from other data [source: John Breslin, in coversation, later also Christopher Schmidt while reviewing this document (on #foaf)].

This ontology defines 6 properties. 3 are super-properties of foaf:mbox, foaf:weblog and foaf:homepage that are not IFPs. 3 are sub-properties of this first 3 that not only are not IFPs, but which are of the typed as from the complement of owl:InverseFunctionalProperty, if a resource has a value for one of these properties it is not the only such resource. For example if a person has a shared_mbox then at least one other person or agent also has it.

In developping this ontology the author is in no way criticising the inverse functional nature of the existing FOAF properties. Rather in providing non-IFP versions not only do I hope to enable more information to be expressed in FOAF, but also to remove the temptation to mis-use them when inappropriate which reduces the value of the IFP nature of the FOAF properties by increasing the number of cases where “smushing” results in incorrect data.

Suggested Use-Cases

One suggested use-case for this is that instead of software which produces FOAF files based on user-input either asking the user to only use properties which apply only to them (or the person or agent in question) or else not mentioning the way these properties are used in FOAF and hoping for the best, they could ask for these values and then ask whether or not they are shared. The author believes that this is more likely to result in correct data.

Another use case is when existing data is being mined for FOAF data. For example when mining email addresses one of the three cases can be true:

1. The address is known to be used by only one person, and “smushing” can be performed safely.
2. The address is known to be used by more than one person, and “smushing” will produce inaccurate results.
3. It is not known how many people use the address, and “smushing” may produce useful results, but should not be relied on to be completely accurate even if the source data is.

Note On Modelling

In the case of the properties which are known to be shared between two or more agents, this could more richly be modelled stating that the agent is a member of a group and that the group shares this property. This is arguably more useful. However it comes with two problems:

1. The relationship between the agent and the property is now indirect, more work is needed to make use of it when, for example, finding an address they can be contacted at.
2. It would be most desirable to use the IFP properties provided by the FOAF vocabuary in relation to the group. However this is problematic. The statements “Alice is a member of the group AliceAndBob” and “The group AliceAndBob have a ’blog at http://aliceandbob.example.com/” does not necessarily entail that Alice writes for that weblog, any more than “AliceAndBob are a group of two people” implies that Alice is a group of two people. Rather we need to explicitly state “All members of the group AliceAndBob write for the ’blog at http://aliceandbob.example.com/”, which is not the semantics of the FOAF IFP property. Attempting to use the foaf:weblog property either removes the knowledge that Alice writes for the blog or, worse, could lead to incorrectly believing that someone engages in some activity or has some attribute because they are a member of a group that does.

Because of this, while modelling the group of people that share one of the properties detailed in this ontology may be useful, it does not adequately express what this vocabuary is intended to express.

Omitted IFPs

The main (sole?) use of foaf:mbox_sha1sum is as an identifier, and hence there is no real value in a version which is not an IFP.

Similarly foaf:aimChatID, foaf:icqChatID, foaf:jabberID, foaf:msnChatID and foaf:yahooChatID are identifiers within various systems and it is probably of little or no value to document super-properties of them which are not IFPs (I’m not sure about this and welcome feedback).