Re: Requirement: queries written as RDF

On Apr 08, 2004, at 18:02, ext Eric Prud'hommeaux wrote:

>
>
> I suggested that expressing RDF queries as graphs that can answer
> those graphs. Patrick dismissed this as bad engineering,

I'm sorry, but I think you perhaps misunderstood what I was calling bad
engineering.

I was saying that merging query graphs (which constitute hypthetical
claims to be proven) with "normal" graphs (which constitute accepted
claims by some authority) was bad engineering, because it mixed up
the distinct status/nature/purpose of those different types of graphs.

I also think it's generally a good idea to keep the queries distinct
from the focus of those queries, not that there couldn't be some
special cases where that could be useful. It's akin to autogenerated
program code created and executed at run time. Sometimes it's useful
to do that, but it also has the potential for generating bugs that
are (practically) impossible to resolve.

The bottom line is that mixing query graphs with non-query graphs
can be considered dangerous and a highly potential source of grief.

> but I think
> it's equally likely that creating RDF documents that you don't mean is
> bad practice. For instance, CityBank asks
>   ericP trw:creditRating trw:badRisk ?
> and gets back no matching arcs. If they asked that question within the
> xml element rdf:RDF, the data that they've just sent via whatever means
> to some collection of servers out there on the net has CityBank saying
> that I am a bad risk. Yes, we can draw careful circles around these
> protocols and say "these are NOT expressed as assertions", but I think
> that's a risky practice.

Ahh, I think I'm beginning to see where your coming from. Some RDF
APIs don't allow one to query across distinct graphs -- i.e. the
query is in one graph and the knowledge to be queried is in another
graph -- thus if one wishes to "test" the claims of the query, one
*must* merge the query graph with the target graph and hence face
the potential of the query "corrupting" the results.

Well... er... I guess I'd just suggest enhancing the API or finding
a more capable/flexible one...

>
> Another option is to hide the query arc in a reified graph where the
> semantics of some term in the graph stipulate the propositional
> attitude. A consumer of the data will NOT see
>   ericP trw:creditRating trw:badRisk ?
> but instead an encoding of that question that forces them to confront
> at least one term that says "this is a _question_". Architecturally,
> I think this is a safer way to go and provides a less rigid set of
> requirements for the query protocol to insulate itself. In particular,
> I think this is crucial if we adopt Rob's proposed requirement that
> the query lang be useful without the protocol (to tell it not to
> express anything as a truth, in this case).
>
> Third possibility (my favorite), leave this hard work for later. Don't
> bother defining the RDF model representation of a query right now. Use
> a languge that doesn't have any implications in the RDF graph. That
> does not preclude us from using an RDF syntax, we just have to change
> the spelling of the namespace. I'm sure that alarmed 90% of the people
> that read it, but I think it _does_ provide an opportunity for tool
> reuse (with some slight tinkering), and keeps us from pooping where
> we eat by confusing questions with answers.

IMO, any RDF API worth its salt should not force you to poop
where you eat.

It seems to me that you are rejecting queries expressed in RDF
due to the limitations of one, or a few, particular RDF APIs.

Patrick


>
>>> Or do we have a solution without a problem?
>>>
>>> Dirk
>>>
>>> -----Original Message-----
>>> From: Howard Katz [mailto:howardk@fatdog.com]
>>> Sent: mercredi 7 avril 2004 7:08
>>> To: Eric Prud'hommeaux
>>> Cc: Rob Shearer; public-rdf-dawg@w3.org
>>> Subject: RE: Requirement: queries written as RDF
>>>
>>>
>>> I got several responses back from members of the Query wg on the 
>>> XQueryX
>>> question. I particularly liked this one. I don't know if it'll shed 
>>> any
>>> light on our own issues, but it's delightfully clear and succinct. 
>>> The
>>> author prefers to remain anonymous.
>>>
>>> In response to a question on why XQueryX:
>>>
>>>> (1) An XML-based syntax was considered easier for machines to
>>>> generate and exchange than a human-oriented syntax that would
>>>> require some sophisticated parsing.
>>>> (2) If queries are represented in XML they can be treated as data
>>>> and you can run XQueries over a collection of XQueries.
>>>> (3) Since XML is known to be an answer to all questions, it must be
>>>> an answer to the question "What would be a good format for 
>>>> expressing
>>>> queries over XML data"?
>>>
>>> In response to a question on the technical difficulties that
>>> arose once the
>>> requirement was formulated:
>>>
>>>> Once the requirement for an XML query syntax was adopted,
>>>> arguments immediately broke out over the level of detail at
>>> which a query
>>>> should be broken down into XML elements. The working group
>>> finally settled
>>>> on two separate approaches that represent extreme points on the
>>> spectrum:
>>>> (a) The whole query is wrapped in a <query> element, and otherwise
>>> unchanged.
>>>> This approach obviously does not take the XML syntax requirement 
>>>> very
>>> seriously.
>>>> (b) The query is parsed, and each and every node in the parse tree
>>> (including individual
>>>> operators, function calls, steps in path expressions, etc.) is
>>> represented
>>> by its own
>>>> element, thus making the query incredibly verbose. This format is
>>> obviously useless to humans.
>>>
>>>> At various times and places, people have attempted to define some
>>> intermediate point
>>>> between these two extremes. These attempts have always ended in
>>> rancor and
>>> controversy.
>>>
>>> Finally, in a follow-up clarification:
>>>
>>>> I believe that the editor of the XQueryX specification is currently
>>> pursuing both approaches
>>>> (a) minimal expansion and (b) maximal expansion. Both will be 
>>>> defined as
>>> valid forms of
>>>> XQueryX.
>>>
>>> Just to close on a personal note, I've always felt that XML is
>>> the answer to
>>> all questions. I'm now coming to feel increasingly that RDF is
>>> even more so!
>>>
>>> Howard
>>>
>>>>> On Sun, Apr 04, 2004 at 09:23:14AM -0700, Howard Katz wrote:
>>>>
>>>>    [snip ...]
>>>>
>>>>>> I certainly agree with the sentiments of the second, "human
>>> readable"
>>>>>> requirement. Interestingly enough, the third, "XML" requirement
>>>>> has been the
>>>>>> one that's caused the group the most difficulty to my
>>>>> knowledge, and at the
>>>>>> moment conformance with this requirement has been downgraded to
>>>>> optional. I
>>>>>> don't know what the major issues have been, but it might be
>>>>> interesting to
>>>>>> know, if only for the sake of curiosity.
>>>>>
>>>>> Can we go beyond the meta-lesson of "that may be hard. it's been 
>>>>> hard
>>>>> in XQuery" to some of the particular problems that requirement 
>>>>> caused
>>>>> the XQuery WG? Also, was this requirement born of some compelling 
>>>>> use
>>>>> cases, or a general notion that it's good practice to express 
>>>>> anything
>>>>> in XML?
>>>>
>>>> I wasn't trying to impart a particular lesson. My intention, not 
>>>> knowing
>>>> what DAWG members know or don't know about it, was simply to
>>>> provide data on
>>>> the experience of the Query wg in the event that might prove
>>> useful to the
>>>> group. In response to your questions, I've asked several
>>> members of the wg
>>>> about their XQueryX experience. If they see fit to pass that on
>>>> to me, I'll
>>>> be happy to share it with the group.
>>>>
>>>> Howard
>>>>
>
> -- 
> -eric
>
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +1.857.222.5741 (does not work in Asia)
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other 
> than
> email address distribution.
>
>

--

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

Received on Tuesday, 13 April 2004 04:24:48 UTC