Re: Graph labels vs. graph names.

On 05/10/11 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
> FOAF)
>
> 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 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.

If we fix a meaning then it seems we either end up with an ideal, 
general mechanism, (1, if I understand it correctly - name the thing 
returned by the act of deferencing a URL), but which is more complicated 
than needed for common cases.  But if we fix on the common cases, it 
precludes the more specialised ones.

As long as they don't conflict, and they don't by sensible choice of 
URIs, they should not be an interoperability problem. If there is 
conflict, it's bad naming, which is always going to be possible.

c.f. RDF lists : general mechanism, reuses existing concepts (triples), 
but unwieldy in practice

 Andy

Received on Wednesday, 5 October 2011 13:45:25 UTC