[foaf-dev] beyond foaf:mbox_sha1sum

Story Henry henry.story at bblfish.net
Tue Dec 22 15:03:07 CET 2009

On 22 Dec 2009, at 13:26, Steve Harris wrote:

> On 22 Dec 2009, at 13:15, Story Henry wrote:
>> On 22 Dec 2009, at 12:00, Mischa Tuffield wrote:
>>> As for the blacklist of IFPs, we too have a blacklist of IFPs, which we flag up in the FOAF validator. We also found that many people use the foaf:homepage property to point to their browser's homepage. And as a result we had to blacklist, http://www.google.com, yahoo.com, and bbc.co.uk to name a few.
>> :-D That is funny. I had not thought of that way of reading the foaf:homepage relation.
>> The problem here as with mbox sha1 sum really is not the ontology, it is wrong data on the web. (Though I think with sha1 sum there are reasonable arguments that it is not an IFP).
> I disagree about that one. There are cases with most (all?) of the other IFPs where a FOAF file may meet the spec, but they're not strictly inverse functional.
> E.g. if I own http://foo.com/, and use that as my homepage, then the domain name lapses, someone else buys it and uses it as their homepage.
> You have a FOAF document, last updated 2009 saying:
> #steve foaf:homepage <http:/foo.com/> .
> and one from 2010 saying
> #alice foaf:homepage <http://foo.com/> .
> Neither of them is/was incorrect, but foaf:homepage is not really an IFP in this case. However these cases are sufficiently rare that you can get away with it, and any sufficiently comprehensive FOAF processor has to deal with loads of issues like this anyway (caused by typos, mistakes and so on).

That does not yet prove that foaf:homepage is not inverse functional.

  You can argue that the statements you made about that being your home page were correct, but would now be wrong if you continue publishing them. HTTP has expiry mechanisms for representations, and people reading those need to take that into account. So 
  - don't continue to reason on expired representations. 
  - changes in life may make sentences that were true, false. So when things change, you need to update things. In real life if you get married, you have to make changes to your passport.

   If we do still want people to be able to make statements about pages having belonged to them, we should perhaps find extensions of foaf that allow for time slicing of resources. Then one could say that one had a foaf:home page over a period of time belonged to me.

  This would be very useful for example to speak about the period of time a public key identified someone. 

   For a bit more about this topic see an older article of mine that shows how this relates to an old issue in database theory between validity time and transaction time


   This also brings out the importance of contexts, and Guha's foundational semantic web work


The above shows even more why you need to help people see the consequences of their statements. This is what will help them fix things.

>> To stop this one has to find friendly ways to make people think correctly about what they are doing. This is a subtle user interface job. It has to be somewhat similar to what we do when someone makes a mistake in speaking. So if someone says they are the last remaining ancestor of the King of Scotland [1] we could laugh out loud, or suggest that they look very good for their age.
> Sure, but the problem is that a lot of FOAF is exported from other systems, and the other systems usually just wanted something to link from the users "homepage" profile text, a link to the BBC is pretty harmless there.

It is harmless if you don't merge the information that it publishes. Just like spam sites and other crooked sites are harmless if you don't believe what they say or don't use them.

The way not to use them is not to link to them. 

> Sites exporting FOAF could go back and make their users all verify that the think they've said is a "homepage" is what we think of as a homepage, but that seems a little unlikely.

Only because we don't have tools that show the consequences of publishing this information. My guess is that as we build useful, and valuable tools that show these consequences, this will lead to people who don't read specs to understand the meaning of the statements that they make.

It may be that for relations such as this we need to accept that they were published in a world where no body did any inferencing, and so that usage is such that the inferencing statements we tried to force them to have are not in fact valid. So we may need to change the ontology. But I think we should first try to create flexible services that show what the consequences of a statement are. In any case you will not be able to stop people publishing spam or writing mistaken foaf. But you can crete incentives to do it right.

The whole discussion indicates that when we add inferential semantics to statements we should also have services that use this inferential semantics in a real and direct way. We need meaning as use to complement declarative meaning.


> - Steve

More information about the foaf-dev mailing list