- 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