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

 >but the endpoint probably won't let you substitute the one graph name 
 > for the other in a query and still return the same results.

If the engine is capable of handling the fact in the dataset that:

<http://www.example/named-graph> owl:sameAs 
<http://www.example/another-named-graph>

in the dataset and so making

GRAPH <http://www.example/named-graph> { ... }

work on

GRAPH <http://www.example/another-named-graph> { ... }

then that seems OK to me.

Similarly for GRAPH ?g {}

-----

We have (SPARQL 1.0 sec 8.2.2):
[[
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). 
For further details see [WEBARCH].
]]

so <http://www.example/named-graph> is the document, not the graph 
value. Saying <http://www.example/named-graph> is reading into the IRI 
something based on the human interpretation but it's commonly done.

 Andy




On 13/07/2010 7:41 AM, Steve Harris wrote:
> I don't think that we should try and gracefully handle situations where people assert nonsense in other graphs, that's just opening can of worms.
>
> If the two graphs really are owl:sameAs then it should be fine, and if not then the fault lies with the original asserter, not the SD document IMHO.
>
> Depending on the cardinality of sd:graph, and the predicates used to the right of it, it may be an error to assert owl:sameAs where it's not literally true anyway.
>
> - Steve
>
> Sent on the move.
>
> On 13 Jul 2010, at 03:35, Gregory Williams<greg@evilfunhouse.com>  wrote:
>
>> Damian Steer recently wrote to the comments list[1] about the naming of named graphs in the service description document. This is the same issue that Sandro brought up (I think at F2F2). Briefly, the current SD document suggests modeling datasets and named graphs like this:
>>
>> [] a sd:Dataset ;
>>     sd:namedGraph [
>>         sd:name<http://www.example/named-graph>  ;
>>         sd:graph [
>>             # graph description goes here
>>         ]
>>     ]
>>
>> Damian suggests that problems arise if
>>
>> <http://www.example/named-graph>  owl:sameAs<http://www.example/another-named-graph>
>>
>> This would suggest the service description entails
>>
>> ... sd:name<http://www.example/another-named-graph>
>>
>> but the endpoint probably won't let you substitute the one graph name for the other in a query and still return the same results. Sandro had suggested that the graph name should really be described using an xsd:anyURI-typed literal.
>>
>> Andy had a nice use/test case[2] for graph names in SDs that I think is compelling, but breaks (or become much harder) if names are literals and not resources. Basically Andy showed several queries over a dataset comprised of both the service descriptions and the named graphs which the SD describes.
>>
>> My gut feeling about this is that the owl:sameAs problem seems only to be a problem if you are actually working with OWL entailment. If the endpoint claims to support OWL entailment *and* asserts the owl:sameAs relationship between the graph names, then I would expect Damian's logic to be true and for there not to be any problem. On the other hand, if the endpoint doesn't use OWL entailment, or if it doesn't assert the graph name equivalence, I wouldn't expect to be able to use the graph names interchangeably. Is this a reasonable distinction to make? I'm not sure how we'd expect an endpoint to know about and reflect an external (and possibly erroneous) owl:sameAs statement, but maybe I've missed something?
>>
>> I'm interested in hearing opinions on this issue (particularly from Sandro and Birte) as its come up twice and makes me nervous about getting the modeling right.
>>
>> thanks,
>> .greg
>>
>>
>> [1] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Jun/0011.html
>> [2] http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0088.html
>>
>>
>
>
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.

Received on Tuesday, 13 July 2010 10:08:46 UTC