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

FYI, new property together with context and need fwd'd:

TimBL has updated the link ontology to include:

http://www.w3.org/2006/link#listDocumentProperty
   '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,

Best,

Nathan

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