W3C home > Mailing lists > Public > public-lod@w3.org > January 2009

Re: Granular dereferencing ( prop by prop ) using REST + LinkedData; Ideas?

From: Richard Cyganiak <richard@cyganiak.de>
Date: Sat, 3 Jan 2009 12:23:07 +0000
Cc: "Aldo Bucchi" <aldo.bucchi@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>
Message-Id: <FC029A39-31CA-4FC4-8E73-E5B42C2521EB@cyganiak.de>
To: "Yves Raimond" <yves.raimond@gmail.com>


On 2 Jan 2009, at 23:20, Yves Raimond wrote:
<snip>
>> I proposed this solution:
>> http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=20926
>>
>> And some refinements here:
>> http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=20962
<snip>
> This discussion was indeed interesting :)
> I now tend to think that linking to a separate document is a cleaner
> way to go, but I am still concerned about auto-discovery. When you see
> something like:
>
> :New_York :morePersonsBornHere <http://example.org/persons_nyc.rdf> .
>
> in the representation of :New_York, you still need a way to describe
> the fact that :morePersonsBornHere links to a document holding lots of
> :birthPlace properties. Just saying that :morePersonsBornHere
> rdfs:subPropertyOf rdfs:seeAlso won't do the job properly - how can
> you tell before retrieving the whole document?

Yves, the proposal above addresses this. There would be a triple:

     :birthPlace link:subjectListProperty :morePersonsBornHere .

This triple can be either directly in the :New_York description, or in  
the vocabulary (where you'd find it by  
dereferencing :morePersonsBornHere).

The triple tells clients that they should follow  
the :morePersonsBornHere link if they are interested in :birthPlace  
triples. So, autodiscovery is solved.

> But perhaps the approach I proposed when we discussed the void:example
> property could work, in exactly the same way as in [1].
>
> In the representation of :New_York, we could write something like  
> (in N3):
>
> <http://example.org/persons_nyc.rdf> void:example { :al_pacino
> :birthPlace :New_York }.

N3 formulae cannot be expressed in RDFa or RDF/XML. How would you  
serialize this in practice?

> Then, a SPARQL query like the following could find the documents that
> hold information about persons born in New York:
>
> SELECT ?doc
> WHERE {
> ?doc void:example ?g .
> GRAPH ?g {
>  ?person :birthPlace :New_York .
> }
> }
>
> One of the good thing with this approach is that the "patterns" of
> information held in the target document can be arbitrarily complex -

As far as I can remember, all the examples that people have given  
could be addressed with a simple property-based approach. Has anyone  
mentioned a use case that goes beyond looking for a single property?  
If not, then what does the additional complexity of this proposal buy  
us in practice?

“This is good because it can deal with arbitrary complexity” is a  
fallacy on the Web. Usually it translates as: “This is bad because it  
makes the common case harder.”

(I note that the situation here is different from what you described  
in [1]. There it was about annotations on a dataset level. Here it is  
about annotating links that occur within many or all individual  
documents of a dataset.)

Best,
Richard



>
> and the only thing you have to do is to provide an example RDF graph,
> holding something representative of what you put in that document.
>
> Cheers!
> y
>
> [1] http://blog.dbtune.org/post/2008/06/12/Describing-the-content-of-RDF-datasets
Received on Saturday, 3 January 2009 12:23:50 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:19 UTC