Re: Requirement: queries written as RDF

On Thu, Apr 08, 2004 at 07:14:13AM -0700, Howard Katz wrote:
> 
> > >(2) If queries are represented in XML they can be treated as data
> > > and you can run XQueries over a collection of XQueries.
> >
> > That's interesting. A Query expressed in RDF could be treated as RDF. It
> > would be easy to do queries about queries. That's an argument for
> > using RDF
> > (or a subset, or a convertible format).
> >
> > All we have to do know is find a use case justifying this
> > requirement... :-)
> 
> It does sound wonderful, doesn't it? I too would like to know what you would
> want to query in a query. Examples anyone ... ?

Queries are like just about any other piece of intellectual creation,
someone may want to look for them. An app developer may ask google:
  What queries look for annotations of documents
  and give back the body and the creation date?
I think someone is about a million times (per query instance in the
envisioned semantics web) more likely to look for published facts than
published queries.

I suggested that expressing RDF queries as graphs that can answer
those graphs. Patrick dismissed this as bad engineering, 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.

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.

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

Received on Thursday, 8 April 2004 11:02:21 UTC