W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

Re: Reqirement 3.5: subgraph results

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Wed, 5 May 2004 22:05:11 +0100
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20040505210510.GA20219@login.ecs.soton.ac.uk>

On Thu, May 06, 2004 at 05:03:38 +0900, Eric Prud'hommeaux wrote:
> > If a query includes some extension function (after 3.3), say a function
> > that takes a radius and the URIs for two geo-spatial co-ordinate nodes and
> > returns TRUE if one is in the radius of the other. The complete graph used
> > to answer that query is not neccesarily known to the query engine -
> > especailly if the function is implemented at a lower level. Asking
> > extension functions (for example) to give the triples that it used to
> > answer the question seems unneccesarily onerous.
> I don't think we will be able to write a specification for this
> scenario anyays. How will we specify the semantics of query
> opperations on data sets that aren't RDF?

I was thinking of the situation where the data is all in RDF, but all the
triples that are required to answer the query are not explicitly mentioned
in the query.


placeA      has-name		"A"
placeA      has-latitude	10.12345 
placeA      has-longitude	4.5678
placeB      has-name		"B"
placeB      has-latitude	10.3 
placeB      has-longitude	4.6

SELECT ?name
WHERE (?loc, has-name, ?name)
AND is_near(placeA, ?loc)
> How do we know the client will be as clever as the server? What
> happens if the server gives back a result graph (or set of result
> graphs) and the client can't see how they answer the query? Not a
> problem, I say dismissively. RDF semantics protect the client from
> arriving at contradictory results (with some extra think-work for
> negation as failure). If the client asked for bindings, the user can
> still get his answer. If the client asked only for grpah answers, it
> probably had a reason to do this, like it's federating parts of a
> query to multiple sources. If it isn't clever enough to follow the
> logic of some of the federated sources, the user doens't get that
> solution. The user in that case would have done no better if DAWG-QL
> didn't have a mechanism for communication results as subgraphs.

Maybe it's still useful, but it seems arbitrary to me. The situation where
the query specifies the graph to construct from the bound variables is
unambiguous however.

- Steve
Received on Wednesday, 5 May 2004 17:05:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC