Re: Want GRDDL intro for WG-dummies :)

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