Re: GRDDL and OWL/XML

On May 13, 2008, at 6:18 AM, Harry Halpin wrote:
> (I am assuming that public-grddl-comments@w3.org is a fine place  
> for this discussion,

Fine for me.

> as opposed to public-grddl-wg@w3.org. It would be useful to point  
> these comments back to the public-owl list as well - Bijan? Is that  
> fine?).

For the sake of the OWLWG, if the GRDDL discussion group can come to  
some consensus it believes would be helpful, I'd love to have it  
brought back over. I prefer the detailed discussion not to be  
reflected directly back as we have a lot of other stuff on our plates.

Is that ok?

> Bijan Parsia wrote:
>>
>> On May 12, 2008, at 8:55 PM, Dan Connolly wrote:
> [snip]
>>>> 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. 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).
> Bijan is right here, it is a *should* - the GRDDL specification  
> does not specify any programming language in particular, although  
> we *recommend* XSLT as it is a widely-supported format and the one  
> that to my knowledge all GRDDL transforms use.

Do we not have a stronger point? Isn't the mere fact of an  
*implementation* merely a SHOULD? That is, a non-executable  
specification of a transformation function is sufficient to have a  
GRDDL spec compliant namespace document (or transformation property  
in general).

Controlling text:
""" The general rule for using GRDDL with well-formed XML is:
If an information resource([WEBARCH], section 2.2) IR is represented  
by an XML document with an XPath root node R, and R has a GRDDL  
transformation with a transformation property TP, and TP applied to R  
gives an RDF Graph[RDFC04] G, then G is a GRDDL result of IR."""

(the second paragraph is in "normative green" :)) Going back to GRDDL  
transformation definition (oh, and it's confustion to go from  
Transformation to Transformation Property, presumably TP is a name of  
the trasnformation, not a property of the transformation.)

...ok, I can't find the univocal, normative definition of a GRDDL  
transformation. Section 6  has normative green, but no indication of  
what is normative in that section and for what. The green rule seems  
to give sufficient conditions of  being a TP given an xslt expressed  
transform, but not the converse. This part of the spec seems to  
interweave normative claims, best practice recommendations, and  
normative claims given that you want to do some best practice.

I don't think turning any of the (perhaps implicit) shoulds into  
musts is a good idea. If reference implementations turn out to be  
useful enough, people will produce them naturally. If they don't  
produce/use them naturally, well, that's a comment on their perceived  
utility.

In general, I'd prefer a model that allowed and encouraged a clean  
distinction between specification and (many possible) implementation 
(s). That seems like a much more robust design, both technically and  
socially. I'd also prefer that GRDDL encouraged *variant*  
transformation functions. For example, I might want to GRDDL an  
approximation of an OWL/XML rather than a faithful translation.

[snip]
>> (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...)
>
> However, at the same point, while it makes perfect sense for the  
> W3C not to specify "reference implementations" per se, after all,  
> the reference is the specification. However, this does not exclude  
> conformant implementations. It does make sense for any  
> specification to have test cases and verify that that there are  
> conformant implementations.

Sure. I've encouraged (and worked on) an XSLT implementation, as well  
a Python implementation, of a transformation from OWL/XML to RDF/XML.  
CR generally requires two interoperable, conforming implementations,  
preferably independent developed. The demand is that we go further  
and 1) develop an XSLT implementation as a WG (soliciting someone to  
do it for us is morally the same as doing it ourselves), 2) produce  
this implementation *as a deliverable* (whereas CR implementations  
aren't the WG product...the CR *report* is), and 3) bless this  
implementation by publishing in an autodiscoverable place in W3  
space, in fact, a place that is closely associated with OWL per se.  
These do not seem like sensible things to demand of a WG,  
particularly one concerned with specification.

> I assume OWL2 will (not sure?) have test-cases and conformant  
> implementations for its XML->RDF mapping. If one of those  
> conformant implementations happened to be implemented in XSLT, I  
> think it would make good sense for it to be available as a GRDDL  
> from the namespace doc of OWL 2.

My impression is that "available" means "explicitly and univocally  
available as a auto, typically without user intervention, loaded  
piece of code promised to be complete with commitment from the W3C on  
future maintenance". We've proposed adding a pointer to the CR report  
and this was rejected as violating the GRDDL spec (though, now,  
people are, I hope, moving to the more reasonable claim that it  
violates GRDDL *culture*).

So, I do not believe it makes good sense to do this, esp. given the  
prevalence of high quality implementations that are widely used by  
the OWL community already.

BTW, I expect people to *extend* the OWL/XML syntax in a variety of  
ways...I'm very unclear how that interacts with a fixed GRDDL  
transformation and esp. an implementation.

> Has anyone tried this? I would not encourage them, but again, would  
> encourage someone to do an OWL2->RDF XSLT and see if it can be made  
> conformant.

I hope you see why the correctness of the XSLT is not the only issue.

>> Cheers,
>> Bijan.
>>
> P.S.:
> Obviously, caching should be done to prevent the issues brought up  
> by Henri.

It's not caching alone. DTDs typically don't express all or even most  
of the constraints of an XML format. So too for XML schema (wsdl is a  
great example there). Obviously XSLT is more expressive, but then we  
get *very* far from a straightfoward specing.

> The caching issues should not be a reason to not use GRDDL. The  
> GRDDL specification does not tell implementers how to cache, but it  
> is given as something GRDDL-aware agents should do: "GRDDL-aware  
> agents therefore should not retrieve such documents on every  
> reference and should retain some cache or local memory of the  
> transformations those documents indicate should be applied." [1].

Given that Henri, obviously, is well aware of caching possibilities,  
I think caching is not really a solution. I don't see that it's a  
great burden on users to configure their GRDDL agent for the well  
known namespaces and the GRDDL vendors can compete on the quality of  
those plugins as can third parties working in XSLT. I really don't  
see a development/deployment advantage *other than* monopoly favor  
for the blessed implementation. (Whether the monopoly play succeeds  
is a different matter. However, I think monopoly plays are very bad PR.)

As I said before, there are good cases for web discovered,  
autoloading cases, e.g., when it's ad hoc or for very small minority  
communities, etc. But that's not our case. By encouraging a community  
to demand that namespace document owners provide this kind of  
reference (and not just reference...deployed default!)  
implementation, I predict that that community will engender ill will.  
This is already true in the OWL case. My early perception (as a  
veteren of the WSDL (and similar) debacles) of GRDDL was positive  
because I thought the intent was to encourage very non-intrusive  
behavior. And, for sure, it's better than demanding (or requesting)  
that everything be done in RDF (or bemoaning when it's not), but it  
still has a long way to go.

Cheers,
Bijan.

Cheers,
Bijan.

Received on Tuesday, 13 May 2008 11:02:22 UTC