[foaf-dev] beyond foaf:mbox_sha1sum

Mischa Tuffield mischa.tuffield at garlik.com
Tue Dec 22 14:36:43 CET 2009

Hi Henry, 

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.

Yup, it did make us chuckle when we identified this troublesome IFPs.

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

Mmm, I guess collisions in the sha1 mbox space are still not that likely, but I understand your point.

> 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.
> When someone specifies a foaf:homepage, one can follow through the consequences of this: 
>  - ask them if they want to make it their OpenID, and then give them instructions on how to do this, so that it can be verified. 

I make an attempt at this in the validator. If the FOAF document in question shares any IFPs with other foaf files in our in KB, we highlight them. You can see examples of this when you attempt to validate my foaf file : 


>  - if one knows someone else who has publicly claimed this as their home page, one could ask them if they want to merge their foaf files or keep them separate

We also attempt to use this type of functionality in our foaf-builder, where by we allow you to search for friends by IFP to be added as one of your foaf:knows's.

>  - if from that home page one can find links to twitter accounts, openids, etc,... one can suggest that they be added to the profile.
> By showing the consequences of a statement - ie. by using OWL, and the additional semantics defined in a term's rdf:comment - one can help people understand what they are doing when they make a statement.  And this without them having to read any OWL.  In short we are moving from declarative meaning to meaning as use.
> Let us turn this around, and look at what it would be for a consumer of foaf - something like the Semantic Address Book, or a foaf+ssl protected resource server - to help improve the quality of linked foaf data. The consumer has some weight on the publisher as a potential publisher himself, or as a controller of access to resources. 
> So for the Address Book case. While the user is browsing the linked foaf data web, and comes across someone's foaf file which contains an IFP that would allow it to merge that user with info from another foaf, then the Address Book, could ask the user if it would like to merge the two users, of if more convenient, merge the info but show how this merged information is coming from different graphs. [3] So here the User Agent is keeping track of which graphs it merges and which not. The user himself is the person voting for such merges. If people have wrong IFPs, the users will tend not to merge that user's file, and may want to reduce their direct links to that file too. This in turn creates a pressure on the people with broken foaf to change it - friends calling them, and letting them know about their problem for example.

Sure, you can use our web-services, to help with this task: 

You can use our sameas(name taken from hg) service, to find URIs for a given IFP, or to find further URIs for a given URI. 


Which is turn can be complemented by our forward and backward search APIs



You can see examples of these calls in my foaf file http://mmt.me.uk/foaf.rdf

the triples look like so : 

	<rdfs:seeAlso rdf:resource="http://foaf.qdos.com/reverse/?path=http://mmt.me.uk/foaf.rdf%23mischa"/>
	<rdfs:seeAlso rdf:resource="http://foaf.qdos.com/sameas/?path=http://mmt.me.uk/foaf.rdf%23mischa"/>
	<rdfs:seeAlso rdf:resource="http://foaf.qdos.com/forward/?path=http://mmt.me.uk/foaf.rdf%23mischa"/>

I hope this helps, two things I should mention, currently our FOAF index is a bit old, but this should be updated soon, do watch this space, and we do NO OWL stuff in the foaf.qdos world. All of the functionality has been implemented using a bunch of sparql queries. 


>  Another type of consumer that can create pressure on publishers of foaf, are foaf+ssl enabled web services. If a service gives friends of some group of people access to a resource,
> then it can use the inferencing power of what those people's foaf say to create pressure to truthful foaf. So for example imagine a foaf+ssl enabled voting service, where people could vote on foaf specification changes. The service should only allow each person to vote once. If two URIs have the same home page, then if one votes the other will be counted as having voted too. If there is a mistake, this will soon surface, as people find they cannot vote, who would have liked to. The organiser of the vote will then have to decide what is the case, if both users can't get themselves to fix their foaf. 
>  So it is only by starting to use foaf in ways that make use of the OWL and other inferencing power of the ontology that we are going to create a pressure - probably describable using game theory - towards growing webs of coherent data. But the applications need to be able to give feedback to the users on the implications of their statements. 
>   That is why just publishing linked data is enough. Let the games start !
> Henry
> [1] http://www.wsu.edu/~brians/errors/ancestor.html
> [2] https://sommer.dev.java.net/AddressBook.html
> [3] http://sig.ma/ shows a way to do this. The problem with this service is that because it is trying to crawl the whole web of data, and as it shows a view of all the data, it tends to merge way too much information. In a personal address book, the user has anchors he is starting from and has reason to trust: namely URL given to him by people, or blogs he likes to read. From there he is not going to move very quickly to crawl the whole web, so it will be much easier to keep him up to date on how things are moving.

Mischa Tuffield
Email: mischa.tuffield at garlik.com
Homepage - http://mmt.me.uk/
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20091222/68caa3ce/attachment.htm 

More information about the foaf-dev mailing list