- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Tue, 20 May 2008 12:27:01 +0100
- To: Harry Halpin <hhalpin@ibiblio.org>
- Cc: Chimezie Ogbuji <ogbujic@ccf.org>, Dan Connolly <connolly@w3.org>, public-grddl-comments@w3.org, public-grddl-wg@w3.org
On 20 May 2008, at 00:37, Harry Halpin wrote: > > Bijan Parsia wrote: >> >> On 13 May 2008, at 15:56, Chimezie Ogbuji wrote: >> > [snip] >> I believe that everyone else agrees that the GRDDL spec does *not* >> require an executable, downloadable specification of the >> transformation at the namespace document. > That's a bit strong. Is it? > I think agreement of most of the remaining active members (at least > myself, Chime, David Booth, not sure about DanC and Jeremy) of the > GRDDL WG is that executable code, in particular XSLT, would be useful, That says nothing about spec conformance. I stand by my assertion (which Dan agrees with) that the spec does not require an executable. > and there is no obvious use value in a non-executable version. I think I've provided lots of use value scenarios, but ok. > Linking to a list of implementations from the namespace document > using RDDL would be useful though. And having links to multiple > types of transforms (distinguished by media types as mentioned by > Norman Gray) could be useful as well. What is the use-case of a non- > executable GRDDL transformaton? To spec what a GRDDL agent should do when encountering that namespace. In the OWL case, of course, it was already obvious, but in other cases it may not be. >> Looking at that text, it seems that if we apply your hermenutical >> strategy we'd also end up with XSLT required ("XSLT result tree"), >> however, it seems your view is not demanded even by that snippet. >> We can easily speak of a non-computable function "being applied" >> in various mathematical contexts. Also, the prior text makes clear >> that this is a "should": >> >> """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, though though XSLT2[XSLT2] deployment is increasing. >> While technically Javascript, C, or virtually any other >> programming language may be used to express transformations for >> GRDDL, XSLT is specifically designed to express XML to XML >> transformations and has some good safety characteristics; XQuery >> has similar characteristics to XSLT, though use of XQuery in GRDDL >> implementation is less widely deployed at the time of this >> writing.""" >> >> So, I believe that my preferred strategy is supported by the spec >> and is GRDDL, not merely GRDDLesque. > > I could implemented an OWL-reasoner by writing it down an algorithm > and then publishing it in HTML, ? > would this count as an implementation? I think the answer would > tend to be "no." I thought the GRDDL implementation was, y'know, the GRDDL agent. I'm not suggesting that people download non-executable GRDDL agents. > Generally, if you were selling someone an OWL 2 reasoner, they > would expect code, no? Same with GRDDL. What's "GRDDL"? I mean, without a qualifier. I expect a GRDDL agent to be implemented and to implement various transformations. >> This is an important point to me since various pro-GRDDL people in >> the WG have argued that without an executable we have failed >> according to the spec and thus failed our charter requirements. I >> only endorsed the charter (and encouraged others to so endorse) >> with the (weak) GRDDL requirement because I read the above spec >> text and came to, what seems to me, an obvious conclusion. > > I think people have argued clearly that an executable one could be > useful for RDF-consuming GRDDL-enabled agents that would like to > "glean" some information from OWL 2. *An* executable, not a silently auto-downloadable one. > That's a use-case that I have yet to see an argument against that > caching and warnings about normativity would not address. That's not a use case, that's a deployment scenario. You start with the presumption that GRDDL-enabled agents will not bundle transforms. After all, they don't need to *DO* the coding themselves! Someone can write a free XSLT transform and the GRDDL agent author can download it. >> From a marketing perspective, it feels like a bait and switch. I >> feel like I did due diligence and now am sandbagged. Proper specs >> *cannot* require people to interview members of the community to >> determine what conforming behavior is. That defeats the point! > No-one else in the community has ever brought up the point that the > GRDDL transformation could be non-executable. This is a weakness on your part, not a strength. It's a straightforward reading of the spec. Part of the point of specs is to codify *in the spec* the understanding. One thing I'm trying to convey is that I thought I *was* part of the GRDDL community, broadly construed. But I guess I'm not and people with my sorts of concerns and perspectives are not. (That's fine! Nothing morally wrong with that. Just be aware that it limits adoption.) > Thus, I think your reading of the specification is unique. I am > glad you have brought this up, as no-one has thought this through > before, and it is an intelligent if unusual point. > > I think if you or others do not want an executable GRDDL > transformation, or object to a RDF translation of OWL2/XML to RDF, > that's fine. It is clear you believe an executable GRDDL is > unnecessary or harmful and there is no reason to address RDF- > consuming agents that may not have OWL2XML local transforms. I > would be interested if other members of the OWL2 WG also think this > is the case. Some do, some do not. I'm still unclear why this is a *use* case. Cheers, Bijan.
Received on Tuesday, 20 May 2008 11:35:01 UTC