- From: Jack Berkowitz <jack.berkowitz@networkinference.com>
- Date: Thu, 13 Nov 2003 19:10:54 +0000
- To: Benjamin Grosof <bgrosof@mit.edu>
- Cc: Sandro Hawke <sandro@w3.org>, 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. 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. Best regards, Jack > Jack Berkowitz Vice President, Engineering Network Inference (Holdings) Ltd +44 (0)20 7616 0700 jack.berkowitz@networkinference.com
Received on Thursday, 13 November 2003 14:11:01 UTC