- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 03 Jun 2005 17:47:32 +0100
- To: kendall@monkeyfist.com
- CC: Yoshio FUKUSHIGE <fuku@w3.org>, public-rdf-dawg@w3.org
Kendall Clark wrote: > On Thu, Jun 02, 2005 at 12:26:29PM +0100, Seaborne, Andy wrote: > > >>I propose that if a query contains a dataset description with FROM and FROM >>NAMED then these describe the dataset fully (the service wil not sneak in extra, >>unasked for, graphs) >> >>Rational: if the application is describing the dataset, then it wants to know >>that the query will execute > > > That's the rationale? That an application describes a dataset, it "wants to > know that the query will execute"? I don't understand this at all. Did the > sentence get cut off or is that it? > > I don't like this proposal, for the reasons I've already stated. I don't > think we should require publishers to be pure query answering services, and > the "the service can refuse to execute the query" thing doesn't help much at > all. An organization doesn't deploy a service in order to refuse to execute > queries per se; a publishing organization may deploy a service to execute > queries with some particular background knowledge. The proposal is that IF the query describes a dataset THEN that dataset will be used - and not that plus other stuff not described. If the query does not specify the dataset (no FROM/FROM NAMED) then the query can execute against what the service provides. The contract between requestor and publisher is either to use the data set described (inc protocol considerations) or to use the one the publisher advertises. Not some hybrid or something completely different. I am not suggesting all query services require FROM/FROM NAMED. Persoanlly, I expect many services to be about querying one dataset that the publisher provides and that queries have no FROM/FROM NAMED. Andy > > This issue of whether a service may take some other graph into account when > it answers a query is similar to the question of inference. We've maintained > a principled silence about inference. Why can't we maintain it about > publishing services adding to the background graph? > > In other words, part of the objection, I *think*, is that you can't be sure > of the results if a service is adding triples to the background graph. That > it's hard to write tests. Well, you can't be sure of them if the service is > doing one of a vast number of different sorts of inference. > > In fact, these issues, are from one perspective, *precisely* the same: if my > query service does inference (either to named or to background graphs or to > all the graphs in the dataset), that may well mean that triples will be > added to one or to all of these graphs. If we're silent about adding triples > via inference, I don't see the point of not being silent about adding told > triples too. > > I don't see how we can abjure the addition of told triples without also > abjuring the addition of inferred triples. > > Kendall Clark
Received on Friday, 3 June 2005 16:49:29 UTC