Re: Graph naming in Service Descriptions (ACTION-266; discussion of comment DS-1)

On Jul 13, 2010, at 9:45 AM, Sandro Hawke wrote:

> My immediate motivation for this was the use of the property sd:name.
> It's like fingernails on a blackboard to me, saying that a named graph
> has a "name" which is the graph itself.  It's exactly like me
> introducing you to my friend Matt, and telling you that his name is
> actually himself, Matt.  No, not the text "Matt" -- his name is his
> *self*.  His name doesn't start with an M, his name is actually six feet
> tall and drives a Honda.   This is clearly a very odd, counter-intuitive
> (or even nonsensical) notion of "name".

Doesn't the wording in SPARQL 1.0 suggest that we're already in the position of using the graph IRI as a proxy for its name?

http://www.w3.org/TR/rdf-sparql-query/#namedGraphs says:

"""
The FROM NAMED syntax suggests that the IRI identifies the corresponding graph, but the relationship between an IRI and a graph in an RDF dataset is indirect. The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph).
"""

I think I understand your reluctance, but isn't there symmetry to be found in using sd:name to match 'FROM NAMED', continuing to have just a single approach to graph naming (awkward thought it might be)?


> After some more thought, though, I think the problem is with that
> modeling of reasoning endpoints, and that direct-style naming is fine.
> 
> I suggest that, when things are working properly, and modulo propagation
> issues, every endpoint ought to provide exactly the same triples for any
> given named graph G1.   I think that's our only hope for sanity in the
> SPARQL world.
> 
> If you want to provide an end point that offers G1 merged with its
> entailments under some entialment regime E, then call it G2.   And in
> the service description, say G2 sd:derivedFrom G1.   You should
> definitely offer that sd:derivedFrom triple in the service description
> for G2, and it would be nice if you could put it in the service
> description for G1 as well, (along with a few more details, like *how*
> it is derived, linking G2 to E).
> 
> Doesn't that seem a lot cleaner?   Does it have any problems?

My immediate reaction to this is that it will be very problematic for stores that dereference FROM/FROM NAMED URIs to populate the dataset. If I say 'FROM NAMED <foo>', but my store does any entailment beyond simple entailment, then your proposal would have the system use a name other than <foo>, and leave me (the user) unable to refer to the graph in the query with the name I just used to load the graph in the FROM NAMED clause.

> To rephrase it slightly: if you offer two different views, derived from
> the same input, give them different names.

That might be reasonable if you always can provide the two views, but I imagine there are some systems that don't/won't give you the choice or ability to provide multiple views with differing levels of entailment.


.greg

Received on Wednesday, 14 July 2010 17:09:58 UTC