W3C home > Mailing lists > Public > semantic-web@w3.org > June 2010

[Fwd: Re: Delegation and splitting the description of a subject over multiple document]

From: Nathan <nathan@webr3.org>
Date: Fri, 18 Jun 2010 22:48:46 +0100
Message-ID: <4C1BE9BE.8090906@webr3.org>
To: Semantic Web <semantic-web@w3.org>
FYI, new property together with context and need fwd'd:

TimBL has updated the link ontology to include:

   'Relating any original property p and list property P
    such that if doe some document {s P d} then d is a document which
    can be expected to contain statements of the form {s p o} for
    various values of o.'

That's the one I (?we) needed,



Nathan wrote:
> Coming back to this one,
> from: http://www.w3.org/DesignIssues/LinkedData.html
> section: Limitations on browseable data
> """
> One pattern is to have links of a certain property in a separate 
> document. A person's homepage doesn't list all their publications, but 
> instead puts a link to it a separate document listing them.  There is an 
> understanding that foaf:made gives a work of some sort, but foaf:pubs 
> points to a document giving a list of works.  Thus, someone searching 
> for something foaf:made link would do well to follow a foaf:pubs link. 
> It might be useful to formalize the notion with a statement like
>   foaf:made  link:listDocumentProperty foaf:pubs.
> in one of the ontologies.
> """
> Looks like a rather good solution imho, also the same approach as 
> suggested by DanC in swig a few weeks ago when I discussed with him.
> Any further thoughts from the community?
> Best,
> Nathan
> Nathan wrote:
>> All,
>> I'm quite sure that I won't have been the first to come across this, 
>> and have touched on it in the past.
>> We are fast approaching the day where we will need to delegate the 
>> management of certain types of information through to third parties 
>> and split RDF documents /descriptions of a subject over multiple 
>> documents.
>> A couple of common use cases would be:
>> Splitting everybody you foaf:knows in to a different document, a 
>> separate list of accounts, wishlists, favourites, things you created 
>> and so forth (both to keep our PersonalProfileDocuments light and HTTP 
>> / FOAF+SSL friendly, and in order to delegate the management of this 
>> information through to trusted applications)
>> Keeping track of pingbacks, backlinks, documents linking in - if you 
>> consider dbpedia.org/resource/London and a scenario where dbpedia 
>> would want to provide isPrimaryTopicOf links to external resources, 
>> then this would obviously become unwieldy and highly in-efficient to 
>> manage / transfer - not to mention http cache considerations with it 
>> constantly changing, and conflation over management of this data, it 
>> most likely would want to be delegated through to 1 or more third 
>> parties.
>> Previously I have always considered rdfs:seeAlso to be the prime 
>> candidate for this, however I'm increasingly of the opinion that this 
>> just won't cut it (certainly without additional information).
>> If we consider the foaf:knows example for a minute, my first instinct 
>> would be to create a new predicate, linking a person to a document 
>> which  contained who they foaf:knows - but then it dawned on me that 
>> the same situation would arise for many predicates (as illustrated 
>> above).
>> Thus, do we currently have, or can we find a single, simple way to 
>> express that document X contains further information for subject Y 
>> that primarily uses the predicate Z. (I probably described that most 
>> appallingly!).
>> Just to throw something out and borrow from an entirely different 
>> example:
>>   #me rdfs:seeAlso <http://example.org/my-friends> .
>>   <http://example.org/my-friends> foaf:primaryTopic _:myfriends .
>>   _:myfriends owl:equivalentClass [
>>     a owl:Restriction ;
>>     owl:hasValue #me ;
>>     owl:onProperty [ owl:inverseOf foaf:knows ]
>>     ] .
>> Perhaps something a bit friendlier though - thoughts?
>> additional considerations:
>> - signing the documents contents
>> - owl:sameAs
>> - dereferencing (i.e. since the subject would still be #me)
>> Best,
>> Nathan
Received on Friday, 18 June 2010 21:50:01 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:18 UTC