W3C home > Mailing lists > Public > www-rdf-rules@w3.org > November 2003

Re: Rules WG -- draft charter -- NAF

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 13 Nov 2003 22:40:09 -0500
Message-Id: <200311140340.hAE3e9bD010621@roke.hawke.org>
To: Jack Berkowitz <jack.berkowitz@networkinference.com>
Cc: Benjamin Grosof <bgrosof@mit.edu>, phayes@ihmc.us, adrianw@snet.net, www-rdf-rules@w3.org

> Just a couple of basic comments on the draft that has been circulated.  
> The first is a critique.  The second I need some help understanding.
> You state in the draft:
> "Semantic Web Services work such as OWL-S [[[benj: [give OWL-S ref] and 
> the Semantic Web Services Initiative (SWSI) [give SWSI ref, esp. to the 
> draft requirements spec of its Language Commmittee] ]]] has found that 
> while OWL allows a lot to be stated, there is a clear need for rules 
> for this work. [[[benj: Rules in particular are critically needed for 
> representing several aspects of such service descriptions, e.g., 
> security/trust policies, proposed or committed contracts/deals, 
> exception handling, and semantic translation between composed 
> sub-services. /* These are identified in the SWSI requirements 
> documents */ "
> I do not feel that this justification is accurate, in particular with 
> regards to the "e.g." elements.  We are today able to represent 
> security policies, proposed/committed contracts, and semantic 
> translations using OWL-DL and encoding this elements as axiomatic 
> expressions in a very direct fashion and without issue.  In turn, 
> knowledge of these can be obtained through querying our inference 
> platform.  As stated, the justifications do not stand up.  However, if 
> you were to amend your justification to areas that are clearly in the 
> domain of Logic Programs -- the ENACTMENT of policies or alternate 
> courses of action in reaction to problems, then I believe your 
> statement will be more robust.

That makes a lot of sense.  Thanks for the suggestion.

> furthermore in the draft, you explicitly call out elements regarding 
> query and operators, with the following:
> "A standard library of built-in terms such as integer sum, string 
> concatenation, and the like, based on the XML Query functions and 
> operators is in scope, since it clearly contributes to interoperability 
> and utility of rules technology. These functions shall be implemented 
> as RDF properties (using RDF Lists to handle n-ary functions, as 
> implemented in cwm). While it is not required that the URIs of the RDF 
> properties be the same as those of the XQuery functions and operators, 
> where RDF functions and operators terms correspond to XQuery ones, the 
> semantics should be exactly equivalent. @@justify - conversion, reuse 
> of code etc."
> In my opinion, partly this is the wrong approach, but I freely admit 
> that I am missing something, so read my understandings and then correct 
> me, please:
> The W3C has just managed to get XQuery energized, yet we are looking to 
> redo that work in yet another recommendation or method?  Why?  Rather 
> than specify that a re-implementation of the semantics of XQuery be 
> done, why not study the requirements of Xquery that capture the 
> additional semantics and uses needed for OWL & OWL-RULES and make a 
> cogent argument to the XQuery working group to formally extend their 
> recommendation to encompass additional capabilities?  If someone needs 
> exact semantics, why can't they just us XQuery as is??  We have hybrid 
> reasoning working here with a Logic Program that calls out to an XQuery 
> to hit a compiled OWL knowledge base, and it works fine.
> People are going to be spending the next two years building 
> applications using XQuery to hit XML sources as they transition off of 
> straight SQL.  In the next two years, you are hopefully going to see 
> several million people with some ability to use XQuery.  Therefore, 
> companies today are moving in that direction (like us).  If there is 
> yet another query method, at a minimum, this will force me to change 
> software and retrain integrators all over again.  The cost impact will 
> be prohibitive.
> The W3C membership is already asking integrators and developers to 
> learn XQuery.  Saying to them that they need to learn and implement yet 
> another query-oriented or operation-oriented methodology in order to 
> get to the semantic web seems to be yet another barrier in an already 
> bumpy road.  We should be striving for less recommendations, but ones 
> that hang together.

This is a big issue, of course.  I'm not going to do it justice right
now, but I can at least sketch my view of the situation.  (Understand
that I'm paid to work on RDF, which may skew my view, and I certainly
don't speak for the W3C here.  If there is any official position, I'm
not aware of it.)

I think there is a competition between RDF and XML.  It's not a
head-to-head competition (obviously RDF/XML uses XML) but there is a
competition for mindshare and for which technologies will be central
to how users address their problems.  It's a bit like the competition
between relational databases and spreadsheets, or between tea and
plain hot water: the user must decide which to use, but internally,
one option might include much of the other.

I also think RDF will be wildly successful in the long run.  It has
the right level of abstraction, close to the relational model, but
more suited to the open world of the web (and human society).  It
solves problems that people seem to think XML solves, but which XML
does not really solve, like vocabulary mixing.

That said, RDF is not as mature as XML.  There are lots of users who
should not use RDF yet, but need something now.   XML may be their
best bet.   I imagine it was like this in the transportation industry
in the 1920s.   At the start of the decade there were millions of cars
in America -- the Model T had been being produced for 12 years -- but
for long trips or commercial shipping over land, rail was the only
serious option.   (In this analogy, rail is SQL or XML, while cars are
Prolog, RDF, etc.)  By the end of the decade, there was enough
long-distance infrastructure to give users some real options.   Today,
both options still thrive.   But in 1920, knowing the future, and
seeing someone investing in railroads, what would you do?

So the W3C is active in both domains.   

In this specific competition, I'm hopeful it's not zero-sum, that we
can find a way to merge the branches.  In the Semantic Web Activity,
this goal is broadly tagged "XML Integration".  It's not being pursued
as fully as I would like.  I think most people either underestimate
the cost of a second conversion in a few years (along this "bumpy
road"), or have no hope for a general solution.  I'm hoping the Rules
Working Group can make a little progress here in the guise of
developing a nice XML syntax for rules, but maybe that needs to be

Meanwhile, we're trying to avoid any gratuitous competition.  The idea
of the paragraph you quote is that the XPath/XQuery functions and
operators are generally applicable in RDF, so the same ones should be
used.  That way all the users familar with them from either of those
contexts will find exactly what they expect when they come to Semantic
Web Rules.   The draft scope statement for RDF Query also says "This
mechanism may resemble the XPath query used by XSLT and XQuery. The
working group should attempt to draw parallels between this graph
query language and the XPath query language to promote
interoperability and reuse of XPath tools where possible." [1]

So yes, there's some competition, but we're trying to keep it to areas
where it's really necessary, where the RDF and XML models simply

The combined approaches you talk about, and the idea of having the
XQuery WG address the issues as necessary, are interesting, but I'm
not sure how they can be realized.  Isn't an XML query fundamentally
about the document domain, not the problem domain?   Maybe that can be
bridged somehow.  Semantic Web / XML Integration.  Hmmmm.

      -- sandro

[1] http://www.w3.org/2003/10/RDF-Query-Charter
Received on Thursday, 13 November 2003 22:37:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:16 UTC