Re: GRDDL and OWL/XML

Okay, it seems like there is some additional context regarding how this
conversation has played out in the OWL WG that I'm missing.  However, I'll
stick to those portions that are directly relevant to GRDDL where we
disagree below.

On 5/9/08 10:28 PM, "Bijan Parsia" <bparsia@cs.man.ac.uk> wrote:

> On 10 May 2008, at 02:35, Chimezie Ogbuji wrote:
>> 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 mean in the sense that there is little room for any deviation from the
description and a particular implementation (otherwise it wouldn't be much
of a transformation 'function').  Being sufficient for "Independent,
interoperable implementation" is the same criteria.
 
>> (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.

s/description/implementation

You will need to be a bit more specific about how specing by means of an
XSLT implementation is 'widely understood' to be bad practice.  XSLT is the
defacto (platform independent) language for XML syntactic transformations
and thus quite appropriate for describing transformation of XML dialects
(unless fidelity, reproducibility, and such things are not important for the
problem at hand - which I doubt).
 
> I mean it exactly. I do not think it is hyperbole. I think the
> exceptions to this case are very few.

Okay, I guess we will have to agree to disagree on this one.

> 
>> 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.

I'd argue that this particular analogy does not hold: i.e., the risks for
'on-line' validation via remote DTD and 'on-line' generation of GRDDL
results from 'on-line' transformations.  More on this later.
 
> 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'm not sure I follow the correlation here (seems like an apples to oranges
comparison): HTML is a presentation markup language and thus requires
'stand-alone' infrastructure to support (i.e. Entire Browser
implementations), GRDDL is a pluggable framework that is meant to work on
existing infrastructure (most of the pluggable framework directly depends on
the ability to load remote, executable resources).
 
> 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.)

Okay.
 
> 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.

Again, I don't think of the XSLT as a 'second' specification, but a more
concrete implementation of the existing one.
 
> First off, declarativeness does not make something a spec language.

I'm not sure what you mean by 'spec language.'  My point was that given
XSLT's very declarative nature, the functional mapping already written out
above should have very direct correspondence with the templates needed in
the XSLT (for instance).  So, roughly speaking, each row in Table 1 should
correspond to a particular XSLT template (in the first approximation).

> XSLT is a programming language and one that's not particularly well
> suited for formal verification, for example.

I'm not sure why you would think so.  Consider our GRDDL test suite is
mostly implemented via XSLT stylesheets for the very purpose of 'formal'
verification of both the specification and of implementations.

> 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. 

I wonder if you can substantiate that claim, perhaps?

> Thus, in principle, you're no better off than with an
> arbitrary programming language.

I'd have to respectfully disagree with this generalization.  There are
certainly many situations where one is better suited writing out an XML
dialect transformation using a native programming language with a decent XML
binding API, however, where the mapping is highly recursive and mostly
structural, XSLT is the better tool.
 
> 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.

True, that is the additional risk in hosting a live XSLT transform.
 
> 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 certainly can understand the concerns about the additional cost of writing
the XSLT (if it comes to that), but I don't think it would be
'inappropriate' (in the sense you are using), since I would consider writing
the XSLT as an added investment in ensuring the quality of implementations
of the transformations (at least where GRDDL is the mechanism used for
parsing).  

Of course, this investment would need to be weighed with the time
constraints of the group and some assessment of whether the existing
functional definition is reproducible (if it is, then this is a moot point,
IMHO - but again I think there may be some additional context that I might
be missing regarding OWL WG proceedings).

Notice, the GRDDL specification doesn't 'bless' XSLT and is pretty explicit
about there being other mechanisms for implementing a transformation
function, however, there was plenty value in using XSLT to ensure the
quality of implementations in practice as part of the implementation report
(which I imagine the OWL WG will also need to provide).
 
>>> 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.

Yes, I wasn't trying to address *every* point raised, just the ones I felt
might directly help with some closure on this thread.  But, since you
emphasize those arguments, I should say that I don't feel all the points on
that page apply to GRDDL.  Some of them, I actually agree with (in the
larger context of whether it is emphatically a good practice for *all* URIs
in the 'semantic web' to be resolvable), but I'll leave that for a TAG
thread :).  So, for instance, the argument about single point of failure is
a legitimate concern, for sure.  However with regards to:

" But if I donıt have a doctype, my document cannot be validated, right?

The document wonıt be ³valid² in the sense of the term defined in XML 1.0,
but this does not matter. Validity in the sense defined in XML 1.0 is
dubious and overrated."

Consider the difference in what is lost in an XML document that is
well-formed but not valid and a GRDDL source document that is also
well-formed but w/out an RDF rendition due to a required transformation
function not being available.  I'd suggest that the reason XML validation is
dubious and overrated is because (a small) part of its original intent was
to address semantic validity (in addition to structural validity) which is
basically a non-starter for XML by itself and one of the *primary*
motivations for using GRDDL to properly interpret the semantics of an XML
document in a more robust way.

It is this difference in what you can 'glean' from knowing an XML document
is structurally valid versus knowing the exact RDF assertions (licensed by
the author) contained within that makes the DTD argument not applicable
here. 
 
> 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. 

Yes, I was.  And yes, in the end it comes down to how complex this function
is, how well it is suited to XSLT, and whether the WG feels it is time well
spent. 

 


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2007).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Monday, 12 May 2008 19:07:33 UTC