Re: GRDDL and OWL/XML

On Tue, 2008-05-13 at 00:04 +0100, Bijan Parsia wrote:
> On May 12, 2008, at 8:55 PM, Dan Connolly wrote:
> 
> > On Sat, 2008-05-10 at 00:39 +0100, Bijan Parsia wrote:
> > [...]
> >> 3) When you have a normative spec for a transformation function (as
> >> OWL does), adding an XSLT sets up a 'second variant' of the spec (as
> >> well as being a blessed implementation) and one that gets directly
> >> used in spite of it being nominally informative. This is a violation
> >> of DRY (don't repeat yourself) and divides attention from verifying
> >> the actual spec (e.g., with multiple implementations). Worse, bugs in
> >> the program become part of the de facto spec.
> >
> > That's a reasonable argument for not using GRDDL to relate
> > OWL 2 to RDF/XML. If the OWL 2 WG doesn't think that it can manage
> > a reference implementation of the transformation in XSLT*,
> 
> (Remember I think that the W3C shouldn't provide reference  
> implementations at all, so I would make a strongly claim.)

Yes, I remember, but I am not persuaded. Reference
implementations are a good thing when we can manage them.

> > then it shouldn't use GRDDL.
> 
> But I don't think GRDDL requires a reference implementation, nor is a  
> reference implementation a requirement for the utility of GRDDL  

I don't see much utility in using GRDDL if there isn't
an XSLT transformation available online.

I think it's fine for GRDDL-aware agents to optimize
the transformation by having better implementations
installed locally, but without the bootstrap
implementation in the web, why bother with GRDDL
markup at all?

> (e.g., of working with GRDDL implementations to make sure they  
> recognize the normative translation; I think variant transformations  
> might be useful in various contexts as well, e.g., just the class  
> tree (but fully classified) instead of a translation of the asserted  
> axioms; similarly, I might provide *approximation* functions).
> 
> So i see a lot of potential for reasonably coordinated specification  
> of transformation, which is what I understand to be the essence of  
> GRDDL.
> 
> > * or maybe XQuery, though it's hard to imagine the difference
> > between XSLT and XQuery making or breaking the case.
> 
> It doesn't for me.
> 
> > [...]
> >> I feel fine in asking a W3C wg to provide a specification *for the
> >> transformation function*, but it should not be the presumption that
> >> saying "Support GRDDL" means providing an implementation.
> >
> > Presumption? It's a straightforward reading of the GRDDL spec, no?
> >
> > "Developers of transformations should make available  
> > representations in
> > widely-supported formats. XSLT version 1[XSLT1] is the format most
> > widely supported by GRDDL-aware agents as of this writing ... ."
> >  -- http://www.w3.org/TR/grddl/
> 
> People are reading the SHOULD as a MUST.

Really? I am not. I just haven't seen a good reason to make
an exception in this case.

>  That's what I object to. My  
> straightforward reading of the spec is that it is SHOULD. In any  
> case, we supply the transformation in HTML which is way more popular  
> than XSLT :) (albeit, not with GRDDL-aware agents).
> 
> (I certainly wouldn't might pointing to a *set* of implementations of  
> our transformation functions, including web services, etc. Then the  
> GRDDL agent could ask the user which to use/install/whatever. As long  
> as the namespace document is actively maintained, that's not so bad,  
> furthermore, it can point to other lists...)
> 
> Cheers,
> Bijan.
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 13 May 2008 14:00:05 UTC