Naming (Re: Service Description document)

> On 27/04/2010 3:24 AM, Gregory Williams wrote:
> > The second issue is one involving the naming of named graphs in a dataset d
> escription. Sandro had brought this up at the F2F, and I hope he can weigh in
>  on it. Basically, I had the modeling in the document like this:
> >
> > [] a sd:Dataset ;
> >      sd:namedGraph [
> >          sd:name<graph-uri>  ;
> >          sd:graph [ ... graph description goes here ... ] ;
> >      ]
> >
> > I believe Sandro's concern was the use of the URI<graph-uri>  since we're n
> ot actually talking about the resource, but instead a name that we've locally
>  given to the graph (hopefully he'll correct me if I'm mis-characterizing thi
> s). Instead, he suggested that it should be "graph-uri"^^xsd:anyURI. If we ad
> opt this change then the document should clarify the rdfs:range of the sd:nam
> e property and the Example section should be updated accordingly.
> 
> I'm not sure this is helpful.  The named graph paper uses URIs, as do 
> TriG and NQuads, as well as SPARQL query. They don't use xsd:anyURI.
> 
> The "local name" idea does not seem to me to get round the issue for 
> xsd:anyURI as it's still associating a global identifier with the graph, 
> even if it's not web-naming it.  The use in a web document means we 
> still have a global reference to the thing.

After more discussion, I'm fine with the graph-uri appearing like this
(as a node label instead of as a string), but I still have a problem
with the terminology.

In particular, what the current draft calls a "NamedGraph" is
misleadingly different from what SPARQL offers as a GRAPH.  As Greg
suggested, considerd the situation where we have multiple endpoints
allowing queries against the same graph G (which they all call G) and
where each endpoint offers a different entailment regime.  In this case,
the endpoints will return different triples when asked about G, and the
service description, which may include things like the number of triples
that will be returned, needs to be different.  The number of triples
isn't about G, it's about this endpoints post-inference view of G.
There's a 3-tuple here of (endpoint, graph, entailment-regime).

My two suggestions for what to call that thing:

      - NamedGraphService
           with property sd:graph pointing to G
      - InferredGraph
           with property sd:input pointing to G

Note again that G is what people actually use inside SPARQL, even though
they are actually querying the graph that results from doing inference
with G.  So even though in a sense this inferred graph is what they are
querying, we want to downplay that, since its identity URI, if any, is
not used in the language.,

Of course "InferredGraph" is a little odd when there's no entailment
regime being used, but maybe that's okay.     Any other ideas?

    -- Sandro

Received on Friday, 7 May 2010 18:50:20 UTC