Re: GRDDL and OWL/XML

A few responses below. This is starting to sound like a classic straw man
argument or at the very least like an irreconcilable difference in
philosophy of distributed web-based applications.

On 5/20/08 6:21 AM, "Bijan Parsia" <bparsia@cs.man.ac.uk> 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.

Good luck there.

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

Hmmm.  You must not have not read the use cases document (or the charter
even).  
 
> 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?)

Bijan, this *is* the point of executable programs: to strictly delineate
behavior.  I wonder if you are aware that is a core pattern within web
architecture:

[[
In the code-on-demand style [50], a client component has access to a set of
resources, but not the know-how on how to process them. It sends a request
to a remote server for the code representing that know-how, receives that
code, and executes it locally.
]] -- 
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3
_5_3

> 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 think (judging from your line of argument) that there is no *principled*
means to prevent you from drawing that conclusion.

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

Essentially, every scenario outlined in the use case document you seemed to
have passed over

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

Exactly, which is why I don't think there is any *principled* point that
could be made such that you will draw a different conclusion.
 
> 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.

BTW, that paragraph is not as much provocative as it is condescending.

> For example, I'm told that XSLT is an
> appropriate specification language because it is "declarative".

You missed the point there (I'm hardly surprised).  The value of XSLT's
declarative processing mechanism is in how appropriate it is for describing
XML transformations.  It is appropriate as a specification language by
virtue of its expressiveness alone (it is turing complete).

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

Actually, I'm not so certain (to follow your example of unbridled
candidness)

> merely shouting "declarative" *isn't any kind of
> argument*. 

I haven't been doing any *shouting* here :).  And the argument about the
value of this quality was well stated.

> Esp. when even in this thread there's indication that
> people understand declarativeness to admit of degrees.

Er.. I can't make any sense of that.

> The  
> appropriate issues is whether XSLT is appropriate for *specification*
> which is a different issue.

One that is completely answered by its demonstrated expressiveness.

> Declarativeness (of various sorts) can
> *help*, but it is certainly not sufficient (consider using the
> relational algebra for tree transformations).

I'd rather not (consider using relational algebra for tree transformations),
the thought alone is harm enough.

> XSLT *is* designed, in
> some sense, for tree transformations,

XSLT is designed (in *every* sense) for tree transformations - read the XSLT
groups charter, you might find it enlightening.  Hence, my skepticism about
your understanding of XSLT.

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

Bijan, you will need to be a bit more explicit about this particular
criticism as it seems to lack any recognizable substance (to be blunt).

XSLT is natively expressed in XML (and thus not opaque), it certainly is not
the most readable of languages but I'm not sure if syntactic asthetics alone
is the point you are trying to make here, and finally perhaps you aren't
aware that indeed XSLT is (by definition) able to handle relative URIs.
 
> 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.
> 
> 
> 


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

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 Tuesday, 20 May 2008 14:13:00 UTC