RE: Proposed XQuery requirement and/or objective

Jim-

 

No, I don't think we are too far off here. If you are in favor of a
[surface layer/grammar/concrete syntax] for the DAWG proposed query
language that builds upon a widely-adopted format, then we are agreed in
principle.

 

Tactics on the other hand... ;-)

 

We think XQuery is a better basis for a surface layer for several
reasons:

 

(1)     XQuery is more modular than SQL. It lends itself to a richer use
of its grammar and simple query semantics, without adopting the data
model, than does ANSI SQL. We are _not_ proposing a simple "looks like
XQuery" surface layer here, _nor_ are we proposing a wholesale adoption
of the XQuery data model and XPath. Instead, we feel like a happy medium
of XQuery syntax (language constructs) and grammar (keywords) and simple
semantics (meanings to keywords) should be the basis of the DAWG surface
layer.  For this point, I wholly defer to Rob Shearer - who is an expert
on implementing XQuery over inference engines and SemWeb data structures
- he will correct and augment my language as needed.  

 

(2)     XQuery is a W3C spec. We believe in supporting the W3C
initiatives and making use of the layered architecture principles
advocated by this organization. Barring any technical barriers that are
insurmountable, we think that XQuery should be the natural starting
point for this surface syntax. (apparently the authors of the DAWG
charter did as well)

 

(3)     XQuery is more "general purpose" than SQL. We believe that the
Semantic Web (engines and language specs) will be about far more than
databases or data access. Our customers use our XQuery-based inference
engine for many non-database use cases. For instance, the use of OWL/RDF
for encapsulating business rules than can be deduced at runtime by
enterprise applications. Likewise, many of our customers are using OWL
as a query mediation schema for heterogeneous data access to web
services. Neither of these cases is database-like in its implementation.
We foresee a future where the Semantic Web does far more than provide
"federated databases" or "data integration" style applications. We think
that business rules, business logic, web services interface management,
process management and so forth are important aspects of the long-term
development of the Semantic Web vision that require a more general
purpose query language than SQL.

 

(4)     XQuery has a native XML context. Regardless of all the political
infighting that occurred, the output of RDF and OWL (and most likely
SWRL) specifications was solidly grounded upon XML inside the SemWeb
layer cake. As the foundation of the layer cake, XML serves as a common
syntax for all SemWeb languages, it makes sense to ground the query
layer in a similar syntactic (or surface layer) basis. Further, since
the commitment was made to XML in this capacity, we think it a natural
fit to choose a unified query concrete syntax that is grounded in the
native data representation syntax for semantic web specifications.

 

I feel like there are many other good supporting arguments and rationale
for XQuery, so I reserve the right to add to this list later.  ;-)

 

But for now, these are some of the important reasons why XQuery would be
a better surface syntax than SQL for the DAWG query output.

 

Regards,

 

-Jeff-

 

 

 

  _____  

From: Jim Hendler [mailto:hendler@cs.umd.edu] 
Sent: Thursday, July 15, 2004 3:07 PM
To: Jeff Pollock; public-rdf-dawg@w3.org
Subject: RE: Proposed XQuery requirement and/or objective

 

At 14:47 -0700 7/15/04, Jeff Pollock wrote:

Jim-

 

Points taken, and no hostility inferred.

 

Your counterpoints regarding the adoption of SQL are a great debate to
have.

 

In broad brush-strokes, we are committed to a query concrete syntax
which is grounded in a widely-adopted (and preferably W3C recommended)
representation.

 

Further, in no means do I intend to imply that XQuery would make things
easier on the vendor implementations for RDFS/OWL/Rule components of the
SemWeb - quite the opposite, the implementations may even be more
difficult.  Our point is intended to speak towards our opinion that a
known query representation would speed user adoption rates for semantic
web languages.

 

If early adopters of large commercial organizations were faced with
learning and implementing a wholly new syntax for queries - on top of
what they already have to pay for in human resource expertise - we
suspect, and have encountered, resistance.

 

Anecdotally, we would likely be supportive of the OWL "two surface
realizations" model, as long as one of them was a widely-adopted
standard format.

 

-Jeff-

 

sounds like we're near the same page -- guess what I'm having trouble
w/is the "widely-adopted standard format" -- since I haven't seen the
Xquery proposal, I've been assuming it is some sort of specialization of
Xquery much as RDQL is a "SQL-like" langauge -- guess I'm thinking that
most large commercial orgs have lots of people who speak SQL and could
learn RDQL-like langauge without thinking of it as different (I speak
from experience, I've met a lot of govt folks who have used RDQL with
RDF DBs because "they didn't need any training" - which is more or less
a direct  quote from someone telling me why he didn't take a SemWeb
training course some colleagues were teaching) where Xquery is not yet
on their todo list.  On the other hand, it is clear more people will
move to Xquery as XML DBs slowly get accepted and steal market share
from traditional RDBMS DBs (although right now it is pretty clear which
one if David and which is Goliath) .. so I think I would agree with you
that "as long as one of them was a widely-adopted standard format",
although I'm less sure we would agree which is which :->

 -JH

 

 

-- 

Professor James Hendler
http://www.cs.umd.edu/users/hendler 
Director, Semantic Web and Agent Technologies       301-405-2696
Maryland Information and Network Dynamics Lab.      301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742      240-277-3388 (Cell)