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

RE: Reqirement 3.5: subgraph results

From: Rob Shearer <Rob.Shearer@networkinference.com>
Date: Wed, 5 May 2004 13:25:16 -0700
Message-ID: <CFE388CECDDB1E43AB1F60136BEB497303FDC9@rome.ad.networkinference.com>
To: "Eric Prud'hommeaux" <eric@w3.org>, "Steve Harris" <S.W.Harris@ecs.soton.ac.uk>
Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>

> 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?
> 
> Imagine a SQL interface to get the current weather in Chicago. The
> part of the SQL spec that says results are some expression of a table
> may help us serialize/deserialize the response, but the bulk of the
> spec that defines the results in terms of restriction, projection,
> union, difference and product on the original data will be useless.
> The SQL spec will be useful if the weather data is defined in terms
> of a table by some other spec. That's roughly what I'm arguing for,
> don't try to define a QL that will handle queries on non-RDF data.
> Instead define operator semantics, result sets, test suites in terms
> of RDF dataa and leave the projection of rules into RDF for another
> specification.

This discussion is getting a bit philosphical, but I think the major
issue here is that we only need to define *what* the answers to some
particular query are. We don't need to define how those answers are
found.

The query "is X related to Y via either of properties R or S?" has
extremely clear semantics with respect to the underlying RDF data model.
If you happen to have one specific RDF data model sitting in front of
you, then there is a very straightforward algorithm for getting the
answer. But that's not the *only* way to arrive at an answer. You may
not have the whole data model in front of you; you might only have some
more general knowledge about it. If you happen to know the fact that one
of two edges must exist, you really *can* answer this query about that
data model.

A query language needs to specify the semantics of a query. It does not
need to specify a particular algorithm for deriving those results.
Received on Wednesday, 5 May 2004 16:28:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:19 GMT