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

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 Monday, 14 June 2010 14:46:43 UTC