- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Fri, 9 May 2008 14:12:58 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Michael Schneider <schneid@fzi.de>, OWL Working Group WG <public-owl-wg@w3.org>
On 9 May 2008, at 13:06, Ivan Herman wrote: [snip] > There are already a bunch of GRDDL implementations out there. What > they do is, roughly: look at the XML document or look at the > namespace document of the XML document, find pointers to a > transformation (or several), execute that transformation with some > sort of an engine, and reap the result in RDF/XML. What GRDDL tells > you is how to achieve these steps automatically by just following > the various URI-s placed at some standardized positions. So you are > right that the core is the XSLT transformation because that is what > does the real work, but the issue is to find the right > transformation automatically. It's not clear that there *is* a right transformation here. For example, I could easily imagine having a sensible transformation that yielded only the classified subclass heirarchy. > As Bijan said, the GRDDL specification itself does not mandate the > transformation to be in XSLT. That is the theory. That is the *spec*. Thus, we cannot have a *procedural* argument that XSLT is required. I, of course, never object to discussing things on the merits! We probably disagree on the merits, but that's fine, yes? (Can I remind people that making procedural arguments for a technical choice is an anti-consensus move. > The practice is that all GRDDL implementations that I know about > (in Jena, in OpenLink, in the Tabulator, and probably others that I > do not know about) implement XSLT, and XSLT only. So if we want > existing GRDDL implementations to work with OWL/XML in practice, we > should face this reality (in my view). I've not not faced this reality, fwiw. It's just unclear how it weighs in, all things considered. > The question is whether the WG should develop, or 'bless' an > implementation, and I think that is the core of the disagreement > among some WG members. That's one, for sure. I think, in general, it's *very* dangerous for the W3C to get into the business of blessing implementations. That is certainly what I picked up from working in the web services groups and even in semantic web ones (e.g., the test suite isn't a conformance suite!). > There is one more aspect that we have to consider in this > discussion. The really nice way of using GRDDL would be to add the > relevant pointers to the relevant transformation to the namespace > document of OWL/XML (I say the 'really nice'; it is also possible > to add such a pointer to each individual OWL/XML document, but that > is an extra burden on the user). However, the namespace document is > owned by this Working Group as long as it is around, ie, adding any > pointer into this namespace document is, essentially, a blessing of > that XSLT transform. Which will trigger my objection, yes. This is why having something "informative" doesn't meet my concerns since whether it's de jure informative will have little effect, imho, on the actual effect. > By the way, this would not be unheard of. The RDFa task force of > the SWD and XHTML2 Working Groups has decided to add an XSLT > reference to the XHTML namespace document, so that all XHTML > documents should be GRDDL-able using this XSLT transformation. The > XSLT stuff itself was written by Fabien Gandon, member of that > group. A similar work is done by the POWDER working group that > defines an XML format for what they want to do, plus an XSLT > transformation that is used in a GRDDL mechanism. When's last call for these? I evidently have some work to do :( > I hope this helps... > > Ivan > > P.S.1.: a very practical application that shows why I believe it > would be good to have this mechanism work in practice asap: The > promise is that OWL/XML makes it much simpler to write down an > ontology than RDF/XML. That might be a promise. (More is that you can use standard XML tooling.) Uhm...but if you are using it for primarily for authoring, what prevents you from doing the transform yourself and publishing it as RDF/XML? I.e., using protege or <http://owl.cs.manchester.ac.uk/ converter/> or a command line tool. I can't help think that we aren't solving real problems but merely trying to do something "cool". > On the other hand if, for example, I want to use OWL-R-Full, and I > want to feed it into an OWL-R engine, I have to write it in RDF. > Well, if the GRDDL transformation works, I can write down my OWL-R > ontology in OWL/XML, and let the rest be done automatically without > forcing the OWL-R implementation to implement a dedicated OWL/XML > parser. Uhm...there are existing open source ones. If you, personally, provided an XSLT, they could use that as well. They don't have to implement one. They can't get away with having one in *some* sense. So we're just back to blessing an implementation. If I were oracle I'd be *very* leery about shipping a tool that claimed to process OWL/XML without careful vetting of the implementation. If I were a customer, I'd want Oracle's OWL/XML loader to, for example, scale appropriately (so not just a correct XSLT, but a tuned one; and actually, I don't care how they implement it). I wonder how all this fits in with Turtle, for example. After all, Turtle is an easier way of writing down RDF, but we don't think we need an autoloading way to process Turtle. We accept that Oracle will build or reuse a Turtle parser. > I am not sure Oracle implements GRDDL already or not, but I can see > that mechanism working very well with OpenLink (that has a built in > rule engine, too, so implementing OWL-R there would be a breeze) or > Jena with an upcoming OWL-R implementation... I encourage people to build OWL/XML2RDF converters in all sorts of languages. The more implementations, the better. I myself started an XSLT one. But I think that there is no advantage to this group building one (WGs are bad places for software development) or for blessing one. If good ones emerge, then all these tools can incorporate them at comparatively little cost. If we bless one, we create a de facto alternative standard and hurt the incentive for people to build alternatives. Cheers, Bijan.
Received on Friday, 9 May 2008 13:10:58 UTC