- From: Rob Shearer <Rob.Shearer@networkinference.com>
- Date: Wed, 5 May 2004 13:25:16 -0700
- 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 UTC