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

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.



Received on Tuesday, 13 July 2010 02:35:55 UTC