[foaf-dev] beyond foaf:mbox_sha1sum
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
>> 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
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  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.
More information about the foaf-dev