Re: GRDDL and OWL/XML

Does this mean you are abandoning your "one semweb" argument? (I ask  
merely for clarification...there's a bazillion and two email to sort  
through :)).

On 20 May 2008, at 05:47, Booth, David (HP Software - Boston) wrote:

> Bijan,
>
> To my mind, a GRDDL "transformation" that is not machine  
> interpretable defeats the purpose of using GRDDL: if one were going  
> to do that, one might as well just do that from the OWL/XML  
> namespace document.

Sounds fine to me. One argument I made to GRDDL skeptics was that one  
of the prime points of GRDDL is to *encourage* the development of  
mappings. Since we had a mapping, all that was left was to give GRDDL  
as success story and show solidarity. AFICT, these are not things the  
GRDDL community wants. <shrug> So be it. I know now to oppose GRDDL  
in W3C specs. I shall, perhaps, still encourage it in certain  
circumstances (e.g., ad hoc situations where the processor really  
wants clients to be able to use an XML format but really wants to  
plug into RDF tools). But I don't know. It hardly seems a mission  
critical service.

>   One doesn't need GRDDL for it.  To be clear, if a document  
> consumer had the built-in knowledge to recognize the OWL/XML GRDDL  
> "transformation" URI and dispatch to a special OWL/XML --> RDF  
> translator, then it could just as well have the built-in knowledge  
> to recognize the OWL/XML namespace and dispatch to that same  
> translator without involving GRDDL whatsoever.

I thought part of the point of GRDDL documents was to specify the  
correct behavior of GRDDL clients. If you have an executable, then  
that pretty strictly delineates the behavior. (Indeed, is it  
conforming to *not* use the actual executable?)

But, ok, if the conclusion you want me to draw is that GRDDL is  
inappropriate for W3C specs, I guess I reluctantly will draw that.

I would be interested in genuine use cases for GRDDL which justify  
the various problems and risks of having automatically downloadable  
code with no user intervention not just as a possibility but as the  
sine qua non. If the use case is "lazy GRDDL developers who don't  
want to actually support formats in their code or even maintain a  
plugins page like the rest of the world" (to put it baldly) then I  
shall be robustly unconvinced. Frankly, I will be likewise  
unconvinced by anything involving nose-following, auto-discovery, or  
way-coolness.

Hmm. I looked at the prior paragraph several times. It is a bit  
provocative, but I genuinely don't know how to communicate "what I  
hear" and have heard in these discussions. It really seems long on  
assertion and short on details. For example, I'm told that XSLT is an  
appropriate specification language because it is "declarative". Now  
putting aside the fact that everyone who has said that has to know my  
background and thus have a pretty clear idea that not only do I  
understand the properties of XSLT but I understand them at a fairly  
deep level, merely shouting "declarative" *isn't any kind of  
argument*. Esp. when even in this thread there's indication that  
people understand declarativeness to admit of degrees. The  
appropriate issues is whether XSLT is appropriate for *specification*  
which is a different issue. Declarativeness (of various sorts) can  
*help*, but it is certainly not sufficient (consider using the  
relational algebra for tree transformations). XSLT *is* designed, in  
some sense, for tree transformations, but it's unclear whether it is  
sufficiently analyzable for programs *or people* to allow, much less  
ensure, proper specification, esp. as things get gnary (e.g., dealing  
with relative uris).

The very idea that we need automagical translators for well known  
formats suggests a certain entailment that I find offputting. In a  
land where GRDDL based tools are in the huge minority of web  
tools...or even OWL based tools...it's rather amazing that one would  
insist on an entirely different way of working which has obvious and  
known problems. Indeed, to insist that if one does not work that way  
that one is *breaking* something (two semantic webs), or doing  
something pointless, etc. etc.

Of course, if the value of the semantic web is infinite, and the  
structure of the semantic web is as you believe, then I suppose  
anything will be cost effective. I trust you see why this is not  
generally appealing to those who must shoulder the burden.

Cheers,
Bijan.

Received on Tuesday, 20 May 2008 10:19:18 UTC