RE: Reqirement 3.5: subgraph results

> 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 UTC