Re: Not GRDDL, but GRDDL-like (was Re: GRDDL and OWL/XML)

On 20 May 2008, at 15:01, Harry Halpin wrote:

> Bijan Parsia wrote:
>> On 20 May 2008, at 00:37, Harry Halpin wrote:
>>
> To address your worries, Bijan,  having an XSLT tranform available  
> as a GRDDL transform *does not force* the GRDDL-aware agent to use  
> the XSLT transform if a better or preferred alternative is  
> available to the client locally. Period.

That's something. Could you point to the controlling text of the spec?

> In a nutshell, the use-case - assuming you think having RDF is  
> useful - for GRDDL is that the GRDDL-aware agent, which can process  
> RDF, may *not* have a local transformation for OWL 2, and therefore  
> goes to the namespace document or follows a GRDDL link and  
> downloads (using caching) a transformation (usually XSLT) to get  
> out OWL 2 XML to RDF. This is necessarily not "silent and  
> automatic" as the GRDDL-aware agent often has to explicitly enable  
> GRDDL.

I have some trouble with the "necessarily" and the "often, but ok.  
There's no inherent reason for preferring the namespace document  
then, I presume. If I have some other repository, that's ok?

> *In this case*, I believe the benefit of having an XSLT available  
> for the agent outweighs the costs that have brought up.

Please remember that I believe that there is a benefit here for cases  
I call "semantic stylesheets", that is, cases where the format and  
the transformation are not widely known.

> If Bijan does not believe that is the case, that's fine - and so I  
> think no additional commentary is needed on my part, although I  
> hope others continue to help Bijan.

Thanks for you help!

> However, I would recommend that one does be clear that the  
> objection to the GRDDL transformation is based on believing the  
> above-mentioned scenario is not worthwhile, not on an idiosyncratic  
> reading of the spec.

? First, I think my reading is straightforward from the text. Second,  
I actually believe there is value in speccing a GRDDL transform  
without supplying an XSLT. But if that's not a position anyone else  
likes I'll definitely not push it.

>   And having as many transforms, including locally installed ones  
> that may be preferable to an XSLT one, are great for OWL 2 and the  
> entire SemWeb.
>
> If this is an issue with the charter requiring a GRDDL  
> transformation this should be brought up with whoever wrote the  
> charter.

Well, the point is that I based a decision about the charter on that,  
what is now labeled, idiosyncratic reading of the spec. This seems to  
be a spec and advertising problem. Perhaps no one else will ever read  
the text that way (though I'd be surprised; it seems pretty  
straightforward).

> [snip]
>>> 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.
>
> But that spec would be human-readable list? It seems that would be  
> better connected via RDDL.

How does RDDL instruct GRDDL agents (and authors thereof)?

>>> 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.
> The GRDDL agent executes the transform, but it can not retrieve the  
> transforms from a list,

Yeeees, but this presumes that it must. Which goes back to the  
original scenario, I guess.

> although Norm Gray's solution of having different transforms with  
> different media types with multiple GRDDL links does make sense, if  
> GRDDL-aware agents start using, say Javascript, as opposed to XSLT.
>
> Just as an OWL reasoner reasons over OWL 2, a GRDDL-aware agent  
> executes a GRDDL transform.

I guess I should stop for the sake of all. :) It's clear that y'alls  
*intent* was that things were executable and that they were retrievable.

> A spec list is not executable.  Just as an OWL reasoner written in  
> HTML could not reason with an OWL ontology given by in OWL 2 XML,  
> or one would not expect an actual OWL2 reasoner to reason over  
> "OWL2 ontology" made in say, a UML authoring tool, so we would not  
> expect a GRDDL aware agent to execute or do anything useful with  
> just a HTML file at the end of a GRDDL transformation predicate. A  
> human could, which is why a RDDL link is preferable to a GRDDL one  
> for the spec list.

Ok, that's a delineation, for sure. So if we had such a RDDL  
document, what would you expect GRDDL agents to do? If we don't give  
a GRDDL document (with executable), can GRDDL agents users appeal to  
anything other than usefulness (which seems sufficient) to encourage  
a GRDDL agent author to include a transform?

[snip]
>> *An* executable, not a silently auto-downloadable one.
>
> As I have stated about five times before, it does not have to  
> "silently, auto-downloadable." Local policy could enable the  
> download, and in fact, most GRDDL implementations seem to be able  
> to turn GRDDL "off and on" with command-line options.

Forgive me for being dense, but then why does a namespace author have  
to (ought to?) supply a transform? I mean, is it *just* convenience?  
If so, why are people so hard for it?

> Furthermore, if a locally installed transform was available, GRDDL  
> would probably not be used.

GRDDL *includes* the downloading? I mean, I'm not using GRDDL if I  
don't download (but maybe if I cached, but not if I have a local  
install)?

I'm very confused.

>>> 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.
>
> But where from? The obvious place is the namespace document for GRDDL.

Well, I don't think people have such a hard time finding code. Google  
and spelunking around the OWL web pages should be sufficient, yeah?  
And that's what they'll have to do anyway if the namespaced transform  
executable is poor quality or otherwise inappropriate.

>>>> 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.
>
> It could also be an idiosyncratic reading of the spec

I guess. I don't feel like I had to do a lot reading in, but <shrug>,  
I am only one data point. The fact that the editor (dan) and some of  
the interlocutors (e.g., Chimezie) disagree about this suggests that  
it's not so very idiosyncratic (at the least, it's unclear what's  
*actually* required).

> whose use cases I have consistently would be better served by human- 
> readable explanation at the namespace document and serving a RDDL  
> file with links to other implementations.
>
>> 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.)
>
> We are all part of the community, both GRDDL and wider Semantic Web  
> community, and trying to understand each other's needs I hope!

It's unclear to me. I confess that I am disappointed because I  
thought GRDDL was part of a smarter strategy for dealing with the  
broader web (unlike, say, RSS 1.0 or WSDL's RDF mapping). But it  
doesn't seem that way. By coupling and conflating spec,  
implementation, and a rather strange distribution requirement *so  
tightly* I think we're still too close to the "Put everything in RDF"  
days. The use case document doesn't really help because it starts  
from the premise that the best way to accomplish all those use cases  
is to get it into RDF and use RDF tools. As you well know, this is  
not universally shared. Mash-up and microformats folks don't give two  
tosses for RDF afaict and neither required namespace based anything.

Oh well.

>>> 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.
>
> See first point.

I guess I still wonder what makes GRDDL unique in this respect. I.e.,  
what's the failure e.g., with the microformats strategy? Or the  
browser strategy?

Cheers,
Bijan.

Received on Tuesday, 20 May 2008 16:07:30 UTC