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

Re: Graph labels vs. graph names. (was: Re: complete graphs)

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 5 Oct 2011 15:54:55 +0100
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <D2254802-2097-4294-ABF6-E6C5842C18E5@garlik.com>
To: Sandro Hawke <sandro@w3.org>
On 5 Oct 2011, at 14:21, Sandro Hawke wrote:

> On Wed, 2011-10-05 at 13:22 +0100, Richard Cyganiak wrote:
>> Implementers and users of SPARQL seem to be generally perfectly ok
>> with relying on private conventions. 
> What sort of private conventions have you seen?    I've heard people
> talk about:
>  1. graph tag is the URL they once fetched the graph from
>  2. graph tag is the URL on which they publish the graph
>  3. graph tag is some sort of non-dereferenceable genid
>  4. graph tag is primary subject URI of the graph (eg the person, for

In Garlik we use all of these, and also use "graph tag is the URI we derived data from, appended with the ISO date as a fragment identifier " when mining data from web pages, PDF docs etc.

e.g. <http://plugin.org.uk/#2011-10-05>

This allows us to track changes over time, which would otherwise be difficult.

> It seems to me the variation here is an impediment to interoperability.
> If my code talks to a new sparql server, and doesn't know which of these
> conventions is being used, how can it do its job?   (Feel free to
> replace "talks to a new sparql server" with "fetches a TriG document",
> etc.)

I don't understand the rationale for wanting to normalise behaviour here. We don't mandate a particular structure for subject URIs, for example. In FOAF files I can use any URI I feel like to describe people, e.g. <#me>, <#i>, <http://alice.example/>. Doesn't seem to cause any significant interoperability problems.

- Steve

> I suggest we settle on a sort of merge of 2 and 3, which can in some
> circumstances be stretched to include 1.    When we talked about this
> some months ago, someone advocated 4, then agreed 2 was fine for their
> purposes and probably better anyway.
>      -- Sandro
Received on Wednesday, 5 October 2011 14:55:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:01 UTC