Re: Naming (Re: Service Description document)

Sandro,

Can we ground this discussion on terminology by reference to the 
existing text in the various documents.  So we're referring to the same 
definitions, I dug out the text for the dataset and GRAPH:

Summary:
A "named graph" is a pair of IRI and a graph.
The GRAPH keyword accesses the named graphs.


http://www.w3.org/TR/rdf-sparql-query/#sparqlDataset
[[
Definition: RDF Dataset

An RDF dataset is a set:
{ G, (<u1>, G1), (<u2>, G2), . . . (<un>, Gn) }
where G and each Gi are graphs, and each <ui> is an IRI. Each <ui> is 
distinct.

G is called the default graph. (<ui>, Gi) are called named graphs.
]]

http://www.w3.org/TR/rdf-sparql-query/#queryDataset
[[
When querying a collection of graphs, the GRAPH keyword is used to match 
patterns against named graphs"
]]

On 07/05/2010 7:50 PM, Sandro Hawke wrote:
> 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.

Making this concrete about the text in the service description document:

http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x0daa6f20
[[
3.2.10 sd:NamedGraph

An instance of sd:NamedGraph represents a named graph having a name (via 
sd:name) and a graph description (via sd:graph).
]]

which seems to me to be aligned with what the SPARQL 1.0 says which is 
that a named graph is a pair of IRI and graph.

What is misleading about it?

It might be called a "NamedGraphDescription" but I don't see anything 
about services as it's describing the graph of the named graph in the 
graph collection/dataset.

GRAPH is a keyword for access the named graphs in a dataset.  The first 
part of GRAPH syntax is the naming part (IRI or variable), the second is 
the pattern to match again the graph of the named graph pair.

SPARQL 1.0 calls out the indirection of IRI to graph.  The text was due 
to DanC and it is the compromise we reached - not sure anyone was 
completely happy with it but that's what's in SPARQL 1.0.



> 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).

Could you give the text that presents that conceptualiztion?  I don't 
know where it comes from and it seems at odds with other text that 
covers service (=endpoint) and dataset. I want to understand your point 
better.

http://www.w3.org/TR/rdf-sparql-query/#sparqlBGPExtend
[[
The overall SPARQL design can be used for queries which assume a more 
elaborate form of entailment than simple entailment,
]]
so it's the BGP+entailment applied to the graph that gives the answers. 
We did (in DAWG) consider the idea of "virtual graph" but this does not 
work for all entailment regimes e.g. OWL-DL.

http://www.w3.org/2009/sparql/docs/service-description-1.1/xmlspec.xml#id0x0daa6f20
[[
3.4.5 sd:entailmentRegime

Releates a named graph with a resource representing an entailment regime 
used for basic graph pattern matching over that graph.
]]

which adds the relationship from named graph to 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

In the service description document text it says that domain of 
sd:namedGraph is sd:GraphCollection and sd:Dataset is a subclass of 
sd:GraphCollection.

It would be very useful to have a concrete piece of RDF for an example 
service description for your proposal.

> 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.

There isn't a graph that is the result of inference.  Its the answers 
for a BGP+entailment regime matched over the base data.

Maybe the entailment doc and/or the extension section of SPARQL Query 
needs to make this clearer?

> 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?

 Andy

Received on Saturday, 8 May 2010 16:17:07 UTC