- From: Howard Katz <howardk@fatdog.com>
- Date: Fri, 9 Apr 2004 10:34:29 -0700
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: "Dirk Colaert" <Dirk.Colaert@quadrat.be>, "Rob Shearer" <Rob.Shearer@networkinference.com>, <public-rdf-dawg@w3.org>
> 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. Sounds like an argument *against* an rdf-based query language, if it's main rationale is to be able to query queries. Is that what you're saying, Eric? > > x I suggested that expressing RDF queries as graphs that can answer > x those graphs. > > I suggested that expressing RDF queries as graphs runs the danger that > the query graphs can answer those queries > > 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. Why is this a danger? If I make a query in XQuery or any other query language, that in no way is seen as an assertion of what I'm querying; it's seen for what it is: a question. (And hey, we all love questions! :-) Is there something inherent in RDF that leads to possible confusion between the two? It seems a bit odd to me that could happen. But that perception might be due to my lack of RDF experience... > > 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. I'm not alarmed. This seems quite reasonable in fact. Howard > > > > 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 Friday, 9 April 2004 13:33:45 UTC