[foaf-dev] beyond foaf:mbox_sha1sum

Steve Harris steve.harris at garlik.com
Tue Dec 22 15:21:33 CET 2009

On 22 Dec 2009, at 14:03, Story Henry wrote:
>>> 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
> 	http://blogs.sun.com/bblfish/entry/temporal_relations
>   This also brings out the importance of contexts, and Guha's  
> foundational semantic web work
>        http://blogs.sun.com/bblfish/entry/it_s_all_about_context
> 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.

I agree with everything you wrote, however that doesn't mean that  
there won't be IFP-colliding foaf:homepage triples out in the real  
world (we know there are infact). Just as there are for mbox_sha1sum.

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

But we're looking at data that was gathered for one purpose, being  
republished as FOAF, that's a significant difference IMHO.

It's a matter of perspective, but I'd rather that sites such as  
LiveJournal publish FOAF that's wrong once in every few thousand FOAF  
files, rather than not publish at all.

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

Sure, but I still think we need to guard against this type of misuse.

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

Even in a world where people do inferencing, they can't / won't check  
every user-entered value by hand.

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

Indeed, and robustness in tools. Naively applying OWL semantics to  
real-world FOAF documents is not going to work today, and I doubt it  
will work in 10 years time either.

- Steve

More information about the foaf-dev mailing list