Re: GRDDL and OWL/XML

On 10 May 2008, at 02:35, Chimezie Ogbuji wrote:

>>> How is use of XSLT an anti-pattern?
[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.
>
> I'll leave the compliance criteria to others, but I think that an  
> informal
> description of a transformation function is much better than none,

I'm not proposal an informal one. We have high quality specifications  
which detail the function with a high degree of precision, e.g.,
	http://www.w3.org/2007/OWL/wiki/Mapping_to_RDF_Graphs

> with an
> actual reproducible description

I don't know what you mean by "reproducible". The above specs are  
sufficient, I firmly believe, for independent, interoperable  
implementation. That's our job, after all.

> (i.e. An XSLT document for instance)

An XSLT is not a description, it is an implementation. You can spec  
by means of a reference implementation, but that's pretty widely  
understood to be bad practice. It's certainly no where near the norm  
at the W3C.

> being
> the best case scenario.  But saying it is *wrong* for a working  
> group to
> provide a 'live' transformation function is a bit strong

I mean it exactly. I do not think it is hyperbole. I think the  
exceptions to this case are very few.

> especially since
> these are all semantic web activities

I'm not sure what that has to do with it. This principle holds for  
DTDs and Schemas as well.

> and thus it is natural for them to
> facilitate automatic consumption by agent by providing such material.

My approach no less facilitates automatic consumption of the relevant  
data by agents. I just believe, along with many other people (browser  
vendors, anyone?), that global standards should be directly  
implemented  by the relevant agents. For example, in HTML, it is  
often the case that new features are prototyped using Javascript  
(which is sometimes provided by third parties as for legacy  
purposes), but no one wants to make them part of the formal  
deliverables, or even point to them (necessarily) from the group's  
home page. Browser implementors generally implement features directly  
(though that's a implementation choice they make).

>> I will argue both against the doing and the presumption.
>> First against the presumption: The GRDDL spec, afaict, requires
>> nothing more that the specification of a transformation function and
>> an identifier for it. That is how I read the spec and, during the OWL
>> WG charter debates, how I represented the requirement for "GRDDL
>> support". There's a big difference between requiring a spec for a
>> transformation and requiring an implementation thereof.
>
> Certainly.  But, intuitively, given the nature of GRDDL, the  
> specification
> of a transformation from an OWL/XML document to an RDF abstract  
> syntax is
> more a modeling exercise than anything else

I'm confused. We *already have a specification* of the transformation.

	http://www.w3.org/2007/OWL/wiki/Mapping_to_RDF_Graphs

(Technically, one step is not yet adequately fleshed out. You have to  
go from the XML to the Functional syntax, then from the Functioanl  
syntas to the rdf by the above document.)

So, especially in this circumstance, I think the idea of having a  
second specification (in the form of an XSLT) which *also* is a  
default/reference implementation is a very bad idea.

> (the status quo XML
> transformation function specification language is very declarative).

First off, declarativeness does not make something a spec language.  
XSLT is a programming language and one that's not particularly well  
suited for formal verification, for example. Compare with a EBNF.  
Though research teams have done wonders for XSLT, I would say it's  
practically impossible to do anything with general XSLT other than  
execute it. Thus, in principle, you're no better off than with an  
arbitrary programming language.

Furthermore, since people propose that it be live and widely deployed  
(otherwise, what would be the utility? esp. given the prior existence  
of a spec), software engineering considerations arise. For example,  
it's not enough that it be correct, but it should perform  
appropriately on standard engines.

> I would
> imagine prior effort in mappings to the OWL abstract syntax would  
> be very
> re-usable for this purpose.  So, I agree there is a difference, but  
> I don't
> think it is as large as you characterize it.

There are existing tracking implementations of this transformation in  
the OWL API.

Acutally, I'm totally confused by what you are trying to argue. We  
have a spec of the transformation function. Any XSLT is either an  
alternative spec or "merely" an implementation. Why should the wg do  
the former (and repeat itself), and if it is the latter, then it's  
inappropriate (because we are blessing an implementation which, given  
the time constraints of the group, won't be nearly as well tested as  
existing ones).

>> I believe
>> other people outside the GRDDL community can feel like they were
>> shanghaied into something they really didn't expect to have to do.
>> This means that the reflex will be to resist any GRDDL requirements
>> or requests altogether (which is certainly where I'm leaning now).
>> So, just tactically, I recommend allowing and encouraging the lighter
>> path. My understanding of the spirit of GRDDL was *not* to be
>> intrusive. Requiring people to produce, or even to bless, an
>> implementation is rather intrusive.
>
> Well, it is not so intrusive if the idea is to facilitate automated
> interaction

There's no way in which it is not intrusive. GRDDL folks are  
demanding of the working group that they do an extraordinary amount  
of work which, perhaps often, does not directly affect the main  
constituacy of the XML format. Futhermore, in our case, given the  
prevalence of open source converters...how doe it benefit anyone,  
actually?

Furthermore, I'm not intending to discourage anyone from building  
XSLT implementations of our transformation! Please do! And XQuery  
ones and Python ones as well. There's a reason why CR defaults to  
*two* interoperable implementations. And the working group cannot  
fairly pick one implementation as the Super Awesome one that software  
agents should autopick.

Centeralization of specification goes with decentralization of  
implementation.

> with sources of "GRDDLable" content (in this case, web-based
> OWL content).  I guess it might help if I had a better  
> understanding of the
> GRDDL/OWL usecase here.

I'm not the one advocating it. I think OWL/XML doesn't need GRDDL at  
all. I only didn't object to it being in the charter because I  
thought, reading the spec, we could be lightweight about it and I  
feel enough solidarity that what ever small boost to GRDDL would come  
from OWL using it in this way was worthwhile.

>   Is it being used only as a mechanism for a
> particular XML-based concrete syntax for OWL or is there more to it?

That's it.

You can play with the format from the Manchester OWL repository:
	http://owl.cs.manchester.ac.uk/repository/
or with the converter:
	http://owl.cs.manchester.ac.uk/converter/

>> Against the implementation requirement.
>>
>> 1) The primary purpose of W3C working group is to produce
>> specifictations...standards, in fact. Many members of the W3C (who
>> pay fees, after all) are implementors and vendors of implementations.
>> The W3C, itself, enjoys a great deal of prestige and attention that
>> its smaller members cannot hope to compete with. Futhermore, the W3C
>> has a monopoly of W3C web space. Thus, it has a monopoly on what
>> implementations it not just recommends, but *delivers* to people (via
>> GRDDL agents). This makes it very difficult to compete with that
>> implementation. Since WGs generally don't live very long, things
>> stagnate (i.e., the W3C doesn't generally have the resources to
>> maintain *lots* of software).
>
> I'm not sure I understand where competition comes into play in this
> conversation.

An XSLT sheet is a program. It is software designed to perform a  
presumed useful function. Manchester, for example, has produced an  
alternative implementation of this function (see uris above or the  
owl api). I presume that you'd find it objectionable (as *I* would)  
if the WG decided to point GRDDL agents at:
	http://owl.cs.manchester.ac.uk/converter/
! But how is it better if it points to a program hosted by the W3C?  
(Note: the university of manchester has antecedents going back to  
1824...it's a much more long lived institution than the W3C!)

>> I don't think it's a real burden on GRDDL implementors to find or
>> write a translation implementation from OWL/XML to OWL/RDF. If
>> someone provided a production quality XSLT, the GRDDL implementors
>> could just download it and bundle it. Indeed, I would hope that
>> quality GRDDL implementation would allow users to configure their
>> client for offline or variant use (e.g., using XML Catalog).
>
> Agreed.

I'm glad we agree on this point. My overall point is that I'd like  
flexibility in how one specs a GRDDL transform. Different  
circumstances call for different approaches.

So, for example, I'm rather leery of any WG using an implementation  
to spec a transform function. But in some cases, if the alternative  
is nothing, it might be ok, esp. if the XSLT was very simple and the  
likely data small. That *may* be the circumstance of the POWDER wg.  
But it's definitely not the case for the OWL WG.

>> There is a strong, large, and vocal community which is against
>> putting key parts of implementations of global consensus specs on the
>> web with the intention that it be downloaded and used by
>> implementations. (I'm clearly a member of that community :)) Here is
>> one explication of this line:
>> http://hsivonen.iki.fi/no-dtd/
>> Everything there applies to GRDDL XSLT (or other implemention).

I note you skip over this point...and it's really important.

>> 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.
>
> Hmm.. If the XSLT 'set up' is a correct implementation of the  
> normative spec
> (as a transformation function) how would it be a 'second variant'?

I hope we all recognize that programs have bugs. I'm sure you're  
thinking of a relatively simple, transparent function, but it's not  
the case here. Plus there are checks and aspects of the syntax which  
should be verified by a translator (or someone might think they are  
publishing an OWL DL ontology in OWL/XML, but the translation yields  
an OWL Full one!).

> I don't
> see how use of a live (re-usable) transformation function is a  
> violation of
> DRY.

Implementations published as "the go to implementation" that  
software, without any user intervention, constitute a second  
specification. Users will believe, with some justification, that the  
results of that transformation "are" correct.

>   Implementations will apply the transformation function in a manner
> compliant with the normative definition, so it actually speaks to  
> the value
> of DRY:

You are confused on DRY here. I want to say, in the GRDDL namespace  
document: "The transformation function is give by <pointer to our  
specs>". There may be *many* alternative implementations of those specs.

> The XSLT document is placed in one place as an instance of the
> normative specification

Now I have two sayings, "Use this which I claim implements that". As  
a de facto normative document.

> for the syntax and thus ensures proper use each
> time.

Well, so too for a correct java implementation. The OWL API has had  
more years of effort than any XSLT we are likely to see.

> It seems to me that, having a testable-reusable XSLT implementation  
> of the
> normative specification (especially one as wide spread as OWL) of a  
> syntax
> guarantees a high-level of quality assurance in implementations.\

Again, I'm happy to have as many implementations as possible. But  
then I don't want to put one in a special position (which will, of  
course, discourage additional implementations).

So, please, produce an XSLT! I personally have one partially done.  
But then, please, don't bless one or put a working group in the  
position of evaluating and blessing implementations (after all! the  
W3C doesn't do conformance certification...this is a form of  
conformance certification!) and the W3C in the position of  
maintaining more software.

Cheers,
Bijan.

Received on Saturday, 10 May 2008 02:28:30 UTC