Re: subgraph/entailment

On Wed, 2005-09-07 at 03:47 +0200, Enrico Franconi wrote:
[...]
> Now we have three possibilities:

I'm getting lost. If this is just back and forth between some
people trying to come up with a proposal, I'll stay tuned.

But if these are supposed to be options for the WG to
consider, I need more information.

> 1) replacing "subgraph of" with "entailed by";

Replacing "subgraph" with "entailed by" is not merely
an editorial change.
The difference between "subgraph" and "entailed by" is
visible from test cases, as I recall. The "entailed by"
wording had some appeal to me, but that's not the design
the WG had experience with. In particular, given

	<MarkTwain> dc:author people:twain.

and the query

	SELECT ?who WHERE { <MarkTwain> dc:author ?who }.

using the "entailed by" wording, not only
is binding ?who to people:twain an answer, but
so is binding ?who to _:bnodeN for infinitely many N.

I don't think that's what anybody is advocating. I hope somebody
will clarify, with test cases (or sketches).
And perhaps some use cases to motivate the change.

> 2) explaining that the subgraphing is done on the deductive closure  
> of the original information (clumsy);

It's already possible for a server to chose the deductive closure
of the original information as its background graph.

Do you mean to change the language such that matching is always done
on the deductive closure? I don't see how that's possible in
the general case, given that
any RDF property might be defined with an extent that affects
the deductive closure... e.g. it might have rdf:type XYZ,
where XYZ is a subClassOf owl:TransitiveProperty.

> 3) explaining that the subgraphing on all the models of the original  
> graph (requires some work to find the proper wording).

Likewise, I would need some explanation of that.

> I still prefer (1) for its simplicity and generality.





-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 7 September 2005 02:36:09 UTC