[foaf-dev] Linking foaf and other rdf documents/resources

[Mischa Tuffield]

Bruce/Matt, 

On 29 Jun 2011, at 09:39, Matthew Rowe wrote:

> Hi Bruce
> 
> On 29 Jun 2011, at 01:11, Bruce Whealton wrote:
> 
>> Hello all,
>>                 So, there are a few ways that one can link various profiles, or RDF FOAF files/resources.  I’m wondering if there is a best practice.
>> I had been using
>> <foaf:knows>
>>         <foaf:Person>
>> ...
>>          <rdfs:seeAlso rdf:resource=”http://url/pathto/foaf.rdf"/>
>>         </foaf:Person>
>> </foaf:knows>
>>  
>> But some FOAF profiles I’ve seen setup with method #2.
>> <rdf: Description rdf: about=”http://pathToFileAboutPerson/longstringofcharacters” >
>>       ... information about the person
>> </rdf: Description>
>>  
>> then further down there would be a
>> <foaf: knows resource=”http://pathToFileAboutPerson/longstringofcharacters”/>
>>  
>> I assume that the about="http://pathToFileAboutPerson/longstringofcharacters” refers to a FOAF file but I guess it doesn’t have to link to a foaf file.
>> I wonder if there is a benefit to using method #2 or a best practice that favors this? 
> 
> I don't think that there is a best practice per se, as both are, as you have found, commonly used conventions. Another is to place a link to an equivalent foaf:Person instance using owl:sameAs within the foaf:Person instance in a foaf profile:
> 
> <foaf:knows>
> 	<foaf:Person>
> 		.....
> 		<owl:sameAs rdf:resource="http://pathToFileAboutPerson/hashURI"/>
> 	</foaf:Person>
> </foaf:knows>

Indeed, people do do this, I find it a bit wasteful in terms of number of triples authored, but that is merely personal preference. 

> 
>> I can see that it might make it easier if one had to refer, more than once, to the resource that represents a person (through their FOAF profile) in a document.
>> As one uses more vocabularies and has more extensive rdf files, it becomes more likely that one is going to make numerous assertions about that person (resource). 
> 
> My preference is for your latter example over the former as data is not duplicated in this instance. However, if I was to create new information about a person (for example by exporting it from a Social Web platform) then I would go for the former option of creating a new instance of foaf:Person and then associating additional, existing information about the person to this instance using either rdfs:seeAlso or owl:sameAs.
> 
>> Most importantly though, will there be any difference in the ability of crawlers or other apps to follow the links between various FOAF profile files?
> 
> In theory, no. Any crawler should have built in 'lookups' that traverse the links and dereference any URIs that are described as being equivalent or providing additional information about the instance (i.e. rdfs:seeAlso and owl:sameAs).

I still think the former approach of using bnodes for People, rdfs:seeAlso, and Inverse Functional Properties is not as efficient as foaf:knows'ing a foaf:Person URI, as below: 

If i (a crawler) come across triples such as below in the foaf:Person http://socialnet.example/user/lame#foo's foaf:PersonalProfileDocument: 

<http://socialnet.example/user/lame#foo> foaf:knows _:bnode0 . 
 _:bnode0 a foaf:Person . 
 _:bnode0 rdfs:seeAlso <http://foozle.example/foaf.rdf> .
_:bnode0 foaf:name "Joe Bloggs" . 
_:bnode0 foaf:mbox <mailto:joe.bloggs at lame.example> . 

I would have to fetch all the triples in "http://foozle.example/foaf.rdf", and I would have to sparql for all the foaf:Person(s) in the document, and I would have to get all of people's foaf:mbox's to find out which of the foaf:Person(s)  http://socialnet.example/user/lame#foo was claiming to know. 

Aside from that I am not criticising the approach, what I find really useful about the bnode manner of foaf:knows'ing someone is for when you don't know the URI of the foaf:Person's foaf:PersonalProfileDocument of their foaf:Person URI, as you can simply state, without the rdfs:seeAlso.

<http://socialnet.example/user/lame#foo> foaf:knows _:bnode0 . 
 _:bnode0 a foaf:Person . 
_:bnode0 foaf:name "Joe Bloggs" . 
_:bnode0 foaf:mbox <mailto:joe.bloggs at lame.example> .

^^ is pretty neat from my point of view, allowing one the ability to foaf:know's someone, regardless of whether or not you know what social network their foaf:PersonalProfileDocument resides. 

Regards, 

Mischa


> 
> HTH
> 
>> Thanks,
>> Bruce
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> Bruce Whealton, Owner Future Wave Designs
>> FOAF: http://whealton.info/BruceWhealton1/foaf.rdf
>> Vcard: http://whealton.info/BruceWhealton1/brucewhealtonvcard.html
>> Web Design and Development http://FutureWaveDesigns.com
>> http://futurewavedesigns.com/wordpress/
>> Web Technology wiki: http://futurewavedesigns.com/w/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> <ATT00001..txt>
> 
> --
> Dr Matthew Rowe
> Research Associate
> Knowledge Media Institute
> The Open University, Walton Hall, Milton Keynes, MK7 6AA
> http://people.kmi.open.ac.uk/rowe/ 
> 
> 
> -- 
> The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev

___________________________________
Mischa Tuffield PhD
Email: mischa.tuffield at garlik.com
Homepage - http://mmt.me.uk/
+44(0)208 439 8200  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/20110629/6f11f4ed/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
Url : http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20110629/6f11f4ed/attachment.pgp