Re: Requirement: queries written as RDF

On Apr 02, 2004, at 21:00, ext Rob Shearer wrote:

>
> Just because some other language has a particular attribute is no
> argument that the attribute should be a requirement of this group, nor
> is the fact that several postings have taken that attribute as an
> assumption.
>
> I need help understanding just *why* encoding queries as RDF is
> desirable in its own right.

That's a fair question. Though, it also then would be fair to expect
similar arguments in favor of any other candidate encoding, such
as RDQL, Squish, etc. I look forward to hearing the arguments in
favor of these forms of query expression. (those for RDF are given
below).

> Deciding on such an encoding is very very
> limiting in terms of what our final recommendation could look like,

It doesn't need to be highly limiting. In fact, I think an RDF
encoding keeps things pretty open and flexible, since one can
express nearly anything in RDF. But I think I understand your
concern about nailing things down too early and paint ourselves
into a corner.

> and
> I think we need some clear and concise arguments, supported by use
> cases, for considering such a requirement, and we need to specify the
> requirement clearly enough that we will know to what extent we've met
> it.

Here are just a few arguments which I think are the key ones (and which 
I
hope are sufficiently clear and concise ;-)

1. Our target is an RDF graph. The formal semantics for such a target
graph is provided by the RDF MT. If our queries are also expressed
as RDF graphs, we are able to (a) maximize the intersection of target
and query semantics, and (b) get a head start in defining the complete
semantics of a query.

2. Clients submitting DAWG queries and processing DAWG results will
(almost without exception) be capable of constructing, manipulating,
and utilizing RDF graphs -- typically via a software API. By encoding
queries (and results, BTW) as RDF, this results in reduced 
implementational
requirements for DAWG clients, as well as a more consistent solution
environment (i.e. fewer parsers, serializations, APIs, logical 
operations,
etc.).

3. By expressing queries in RDF, the queries themselves fall within
the target scope of DAWG, which (barring careless syndication of
query graphs with other graphs) will offer alot of utility.

4. Clients which wish to submit a query to a DAWG repository which is
known to not support any inference could employ a reasoner to pre-expand
the query into a set of alternates and submit each to the repository,
syndicating the results (or this could be provided by a specialized
proxy-based query broker). Granted, one could do this if queries were
expressed in other ways, but one would first have to map the query to
RDF, reason about it, and then remap it back to the other form. Much
better to use RDF from the start.

5. Since RDF already provides for arbitrary datatypes, that requirement
is automatically met by using RDF to express queries.


Some use cases (already submitted):

http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0056.html
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0073.html
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0074.html

>
> If RDF serialization falls out of our final design, then I don't see 
> any
> problem with that. But it's a very different situation from specifying
> RDF serialization as a design goal.

Fair enough, and I agree for the most part, in principle.

To some degree, though, since RDF graphs are our target, one
could consider queries expressed as RDF graphs as being an
obvious, natural approach, and non-RDF forms of expression
less obvious. Of course, not everyone may see things that
way ;-)

Patrick


>
>> -----Original Message-----
>> From: Patrick Stickler [mailto:patrick.stickler@nokia.com]
>> Sent: 01 April 2004 23:48
>> To: Rob Shearer
>> Cc: public-rdf-dawg@w3.org
>> Subject: Re: Requirement: queries written as RDF
>>
>>
>>
>>
>> On Apr 01, 2004, at 23:30, ext Rob Shearer wrote:
>>
>>>
>>>
>>> I'd like some clarification of just what we're trying to get at from
>>> this requirement.
>>
>> As far as what I personally mean by this, c.f.
>>
>> http://sw.nokia.com/rdfq/RDFQ.html
>>
>> in particular the broad range of examples at the end.
>>
>> I'm in the process of implementing RDFQ. A very pre-alpha, partial
>> version is accessible at http://sw.nokia.com/rdfq/
>>
>> (no need to point out its shortcomings, it's very preliminary...)
>>
>>>
>>> Are we saying that we want queries to fit into the RDF/XML
>> syntax? I'd
>>> like clarification on just what users and use cases benefit
>> from such a
>>> syntax.
>>
>> C.f. my earlier postings to the WG and to the IG prior to
>> Cannes about
>> this
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar
>> /0056.html
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar
>> /0151.html
>>
>> http://lists.w3.org/Archives/Public/www-rdf-interest/2004Feb/0224.html
>>
>>> My experience is that forcing RDF/XML syntax just makes it damn
>>> near impossible for humans to compose a document without
>> lots of help
>>> from tools.
>>
>> Have a look at the condensed Turtle/N3 query examples in the RDFQ
>> documentation.
>>
>> I think you'll find that they are just as keyboard friendly
>> and readable
>> as Squish-like queries.
>>
>> I.e., in cases where users would need to manually type in queries
>> (rather than use a query UI) they need not be forced to resort to
>> RDF/XML, but can use other more user-friendly serializations of
>> RDF -- while still having the queries remain full/pure RDF.
>>
>>> If queries are being generated automatically, most software
>>> systems are pretty agnostic just what their output syntax is, so I
>>> don't
>>> see RDF representations as helping them much, either.
>>>
>>> Are we saying that we want queries to fit the RDF data
>> model? If so, I
>>> don't think it's met trivially, since just about anything can be
>>> translated into RDF--that's the whole point of RDF.
>>
>> True, but that's alot more work for the query engine and each
>> engine may interpret the non-RDF input in different ways and
>> thus come up with different results.
>>
>> Having the query expressed from the start in RDF puts it within
>> the scope of the RDF MT, which I think is a very useful thing
>> to do.
>>
>> Have a look at the RDFQ materials and then say what you think
>> about this requirement.
>>
>> Cheers,
>>
>> Patrick
>>
>> --
>>
>> Patrick Stickler
>> Nokia, Finland
>> patrick.stickler@nokia.com
>>
>>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 5 April 2004 09:00:01 UTC