Re: Requirement: queries written as RDF

On Apr 05, 2004, at 19:55, ext Rob Shearer wrote:

>
>
>> 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.
>
> I'm afraid I don't buy this one at all. RDF is nothing but a syntax for
> encoding graphs.

???

>
> If you're looking for semantics on RDF graphs, I'm afraid you've got to
> turn to RDFS and OWL.

Yes. Nothing I've proposed was intended to preclude this.

I think you have misunderstood my proposal as simply using the RDF 
syntax
(which I didn't mean) rather than RDF "in its fullness" (which I did 
mean).

> Queries encoded as OWL really do have useful semantics: e.g. an 
> instance
> representing a variable which is a member of some class and inherits
> from some existential to a nominal of another instance, etc., would 
> then
> have well-defined meaning in terms of what could fill that variable.

Great.

>
> No semantics for RDF means no advantage to using it.

It puzzles me that you would think I was proposing using RDF syntax
without semantics since I explicitly mentioned the relevance of the
RDF MT...

???


>
>> 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.).
>
> Whoah- giant giant leap here.

I have a feeling that the only giant leap is your misunderstanding
of what I am saying here. Sorry. Please try re-reading it. Maybe
it will be clearer the second time around.

> Just how do you see people getting this abstract "RDF processing"
> functionality?

Eh? Abstract? I tend to find software APIs to be quite "real" and
concrete tools.

> I was rather thinking that engineers armed with an RDF query language
> wouldn't need any other RDF components to get at the data they want. If
> you've got to be able to process RDF in order to use our language to
> query RDF, then what's the bloody point?

If you have to construct a query, using a software API that allows
you to work with a well-understood form of expression (an RDF graph)
is a benefit, not a burden.

Especially since you have less risk of creating a syntactically invalid
query expression since the construction of the query is via API 
functions/methods
and serialization is handled by the API -- rather than directly 
constructing
the query expression string using string operations.

You're question "what's the bloody point" seems as strange to ask in
this case as in the case of someone using a DOM API to construct an
XML instance -- and thus not having to worry about the arcana of
the XML serialization, but only the logical structure of the instance.

Sorry, but I continue to be puzzled by your comments to my posting. They
appear to be comments to some other posting, not to what I actually 
wrote.

>
>> 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.
>
> This is the only argument I really understand, and I understand 
> interest
> in storing queries in RDF, which is the cool new way to store anything.
> However,
>
> 1) This concern is academic; in real life users are unlikely to care
> very deeply.

I think this remains to be seen. Your assertion does not make it true.

> Witness the world's complete lack of interest in XQueryX.

I don't think you can make your conclusion based on the specific
case of XQueryX. Also, I expect the key motivations for XQueryX
had far more to do with using general XML tools (other than, or
with no special focus on, XQuery) rather than querying queries.

Still, this is not the greatest benefit/argument for having queries
expressed using RDF, so even if this particular argument is discarded
that doesn't mean the proposal to express queries in RDF is without
significant merit.

>
> 2) We still don't have any use cases at all demonstrating this user
> need, and I think we should at the very least come up with a couple of
> use cases for any requirement.

This was an argument for the requirement, not a requirement itself.

>
>> 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.
>
> I have architected both inference engines and query brokers to perform
> the kinds of transformations you describe, and I have never been at all
> tempted to use RDF internally as an intermediary.

Were your solutions intended to be completely system and implementation
independent, allowing for the interaction of arbitrary clients and
knowledge stores operating in (potentially significantely) heterogenous
environments?

I think it's good to keep in mind that just because some particular 
approach
has worked in the past for specific implementations of specific 
solutions
in a controlled environment, that does not mean such approaches will be
suitable/optimal as a global standard aimed at platform and 
implementation
independent solutions.

So just because you have never been tempted to use RDF in the past (and
I fully appreciate why you wouldn't be so tempted) that doesn't mean 
using
RDF for DAWG is not an optimal approach, given the goals typically
associated with standards (as opposed to closed systems).

> Any query broker is going to have to be able to process the query
> language, that language is going to be a lot more specific than RDF, 
> and
> you're going to need more custom logic than generic RDF processing.

Examples?

> Using RDF as syntax just means that you've got to parse RDF instead of
> parsing something else, and to be honest RDF is one of the most awkward
> languages to parse at this point in history. (Okay, Perl, but you get
> the idea...)

Firstly, I'm not proposing using RDF just as syntax. And in fact, the
serialization employed is *irrelevant* insofar as the semantics and
evaluation of the query is concerned. What matters is the query *graph*.

Secondly, there are numerous APIs available in numerous programming
languages for numerous platforms which provide standards compliant
RDF parsers, so why would you ever bother to parse the RDF yourself?

A DAWG implementor would no sooner write their own RDF parser than
and XML impementor would write their own XML parser. True, in some
special cases some folks choose to write their own parsers, but that
is definitely the rare exception rather than the rule. Sorry, but
this argument against RDF insofar as syntactic/parsing issues is
concerned just doesn't hold water. Again, the serialization is of
secondary importance. Serialization is relevant only insofar as
interchange and (for manual input) human usability is concerned.

Thirdly, DAWG implementations are going to have to be RDF savvy
in the first place -- since, er, the target is RDF and if they
don't understand the nature of the target how will they be able
to interpret the results? -- so having queries (and results) also
expressed in RDF constitutes a *shallower* learning curve for
DAWG developers since once they grok the RDF graph and how
RDF/OWL vocabularies/ontologies work, they then grok how to
construct queries and process query results.

Having a non-RDF form of expression for queries (or results) forces
them to both understand and find/create methods to construct (or
process) those other forms of expression -- thus increasing both
the learning curve and the implementational burden (i.e. more
parsers/APIs).

>
>> 5. Since RDF already provides for arbitrary datatypes, that
>> requirement
>> is automatically met by using RDF to express queries.
>
> That's not an excuse for a new requirement; it's a solution for a
> different requirement. Don't confuse the two.

If the satisfaction of one requirement automatically results in the
satisfaction of another requirement, then that is most certainly
relevant when considering both requirements, particularly if the
other requirement has already been accepted and must be satisfied.

No, by itself alone, it doesn't justify acceptance of the requirement,
yet it's not offered by itself alone, but along with a number of other
(stronger) arguements in favor of the requirement in question.

>
>> Some use cases (already submitted):
>>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar
>> /0056.html
>
> The words "let us assume that the input query is expressed in RDF" 
> don't
> make this use case demonstrate the requirement. Again, query brokering
> can be performed quite independently of RDF. I can meet this use case
> without encoding queries as RDF.

I think that all of the use cases could be met in some other fashion 
than
the approach suggested/understood as optimal, as illustrated in the 
given
use case.

The point is not whether one couldn't do it differently, but whether 
doing
it differently would be a *better* way of doing it.

I think the use cases clearly illustrate the utility of having the 
queries
(and query results) expressed in RDF.

>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar
>> /0073.html
>
> Again, I don't see how this demonstrates any requirement for queries in
> RDF. Someone wants to know about people between 16 and 18 years of age.
> There are a ridiculous number of ways to meet this use case which don't
> encode queries in RDF.

As above.

>
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar
>> /0074.html
>
> This use case certainly seems to dictate that queries are RDF, but
> that's the premise of the use case. It's like writing a use case saying
> "a user writes a query in natural language French and gets some 
> answers"
> and then saying "see? we need a natural language processor for French!"
>
> I actually don't really consider this a use case at all; it's just a
> little proto-requirement. There's never any mention of just what the
> user is trying to do; just the presumption that the query language will
> work in a particular way. We might as well have use cases along the
> lines of "a user writes a query in natural language French and gets the
> answers she wants".
>
> A use case is a real problem a user has *now*, in the absence of a 
> query
> language, that a query language could help solve. No user is using an
> RDF API to write a query in our language, because there is no language.

Gee. And here I thought we were creating "stories", not legal briefs...

Perhaps you would like to present a use case which clearly demonstrates
the requirement that queries *not* be expressed in RDF, or that queries
*must* be expressed in some Squish-like language? I think you will find
it just as difficult, or impossible, as it is to create a use case that
clearly shows that queries *must* be written in RDF. You are expecting
something that cannot be done with a (typical) use case.

Use cases reflect *optimal* ways of doing things, and requirements
that fall out of those use cases are intended to achieve *optimal* 
solutions
which allow people to do things in that *optimal* manner.

The use cases I have presented IMO reflect the optimality of using RDF 
to
express queries (and results) in RDF.

Feel free to submit alternate use cases which reflect some other 
optimality.

Patrick


>
>

--

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

Received on Tuesday, 6 April 2004 03:04:35 UTC