W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

[GRAPHS] Follow your graph nose.

From: Fabien Gandon <fabien.gandon@inria.fr>
Date: Wed, 2 Mar 2011 14:04:06 +0100 (CET)
To: public-rdf-wg@w3.org
Message-ID: <1149595757.197438.1299071046156.JavaMail.root@zmbs1.inria.fr>

An other issue that was touched in the discussions about IRI to identify g-boxes/graphs/etc. is the application of the follow your nose principle of linked data to RDF graph [1].

As I remember from the workshop there were at least two opinions on that matter:

Opinion (1) : When I follow the IRI of a graph I should get a serialization of the triples contained in that graph.

Opinion (2) : When I follow the IRI of a graph I should get triples about that IRI.

In other words if I have the following dataset:

:G1 { http://dbpedia.org/page/Antibes geo:lat 43.580833 ; geo:long 7.123889 . }

:G1 dc:date "2010-11-12"^^xsd:date ;
    rdf:type ex:GPSData .

On dereferencing :G1

Option (1) would return 
http://dbpedia.org/page/Antibes geo:lat 43.580833 ; geo:long 7.123889 .

Option (2) would return
:G1 dc:date "2010-11-12"^^xsd:date ;
    rdf:type ex:GPSData .

Now I could see pros and cons for each option:

Option (1) provides an easy way to fetch graphs.
Option (2) seems to me more in-line with practices of linked data where the dereferencing often resembles a SPARQL DESCRIBE <URI>

If I had to chose, I would prefer option (2) to have a more consistent behavior and remain independent of the type of resource identified by the IRI i.e. whether it is a graph or not I always get triples *about* the IRI / Resource. One could then have a vocabulary to allow additional queries e.g.

:G1 rdf:type rdf:Graph ;
    sparql:endpoint <http://dbpedia.org/sparql> ;
    ex:size "42" .

That being said a third option that I didn't see mentioned so far could be to send everything on dereferencing the IRI i.e. the graph together with its metadata.


[1] http://www.w3.org/DesignIssues/LinkedData.html
fabien, inria, @fabien_gandon, http://fabien.info
Received on Wednesday, 2 March 2011 13:04:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:03 UTC