W3C home > Mailing lists > Public > public-grddl-comments@w3.org > April to June 2007

RE: issue-dbooth-9a: GRDDL should be usable in a messaging pipeline [OK?]

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 15 Jun 2007 16:57:07 -0400
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C202C85CD2@tayexc19.americas.cpqcorp.net>
To: "Jeremy Carroll" <jjc@hpl.hp.com>
Cc: <public-grddl-comments@w3.org>, "McBride, Brian" <brian.mcbride@hp.com>

While I find the idea of modeling the message as an information resource
to be rather contorted and unnatural, for the purpose of addressing this
comment I think it is good enough.

Furthermore, since the remaining aspect of this comment can be subsumed
under issue-dbooth-3, this comment can be marked closed to my
satisfaction.

Thank you

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
 

> -----Original Message-----
> From: Jeremy Carroll [mailto:jjc@hpl.hp.com] 
> Sent: Tuesday, June 12, 2007 1:07 PM
> To: Booth, David (HP Software - Boston)
> Cc: public-grddl-comments@w3.org; McBride, Brian
> Subject: Re: issue-dbooth-9a: GRDDL should be usable in a 
> messaging pipeline [OK?]
> 
> 
> Dear David,
> 
> In addition, the text I just pointed you at:
> 
> http://www.w3.org/2001/sw/grddl-wg/base#pipeline
> 
> is intended to address this comment to.
> 
> I will add brief in-line commentary to the first part of your comment:
> 
> Booth, David (HP Software - Boston) wrote:
> > This is a personal comment -- not on behalf of HP.  
> > 
> > [Incidently, I will be happy to help supply proposed 
> wording changes to
> > the GRDDL spec that would address this issue, though this 
> message does
> > not specify them.]
> > 
> > Suppose I wish to use GRDDL in a Unix pipeline in order to make App1
> > produce RDF for consumption by App2 by wrapping App0 and 
> transforming
> > its XML output of App0:
> > 
> >                  App1
> >   +------------------------------------+
> >   |                                    |
> >   |  +------+               +-------+  |               +------+
> >   |  |      |               |       |  |               |      |
> >   |  | App0 |--> XML msg -->| GRDDL |--|--> RDF msg -->| App2 |
> >   |  |      |               | xform |  |               |      |
> >   |  +------+               +-------+  |               +------+
> >   |                                    |
> >   +------------------------------------+
> > 
> > 
> > Some observations:
> > 
> >  - App0 is not "on the web" and does not have a URI.  
> However, I suppose
> > one could consider it an "information resource" in the TAG WebArch
> > sense.
> 
> The draft text treats the XML msg as the information resource, which 
> seems in accordance with RFC 3986 5.1.2, rather than App0.
> 
> >  - Each XML msg is a particular XML instance document -- a concrete
> > sequence of bytes, or "representation" in the TAG WebArch 
> sense. There
> > is nothing vague or abstract about it. No content negotiation is
> > involved.
> 
> The XML msg is then an information resource that is it's own 
> representation.
> 
> >  - Each XML msg is a separate message whose entire 
> semantics are to be
> > exposed by GRDDL transforming it into RDF.
> >  - It does not make sense to talk about the GRDDL results of App0 in
> > general, as though App0 were a static "information 
> resource". It only
> > makes sense to talk about the GRDDL results of a particular 
> XML message.
> > 
> 
> The draft text does not try to make sense of talking about the GRDDL 
> results of App0.
> 
> > 
> > The main reason the spec at present does not adequately 
> address this use
> > case is that in multiple places the spec defines GRDDL 
> results in terms
> > of "information resources" instead of "representations".  
> It does not
> > always make sense to talk about the GRDDL results of an information
> > resource, because that information resource may produce different
> > information content at different times or for different 
> consumers.  But
> > it *always* makes sense to talk about the GRDDL results of 
> a specific
> > representation.
> > 
> 
> A representation is itself an information resource, some 
> representations 
> also have their own URIs and some don't.
> 
> =========
> 
> END OF IN-LINE COMMENTS
> 
> 
> Does the new draft text address the use-case of GRDDL in an XML 
> messaging pipeline adequately, and, if it does, is this comment 
> adequately addressed?
> 
> thanks
> 
> Jeremy
> 
> 
> 
> 
> 
> > For example, suppose an information resource, ir,  produces 
> a different
> > representation each time it is queried -- the current 
> weather in Oaxaca,
> > for example -- and I have two XSLT scripts that I use to 
> glean RDF from
> > them: one extracts the temperature (getTemperature.xsl) and 
> the other
> > extracts the humidity (getHumidity.xsl).  The final RDF 
> should be the
> > combined result of applying getTemperature.xsl and 
> getHumidity.xsl to
> > the *same* representation.  But the spec does not define 
> merged GRDDL
> > results for a particular representation, it only defines them for an
> > information resource as a whole, which could have a jumble of
> > temperatures and humidities from different days.
> > 
> > Actually, to be more specific, the problem is not that the 
> spec *does*
> > define results in terms of information resources -- I don't 
> see big harm
> > in *also* doing that (except that by doing so it introduces 
> unnecessary
> > ambiguity, which I'll discuss separately) and for namespace 
> and profile
> > documents there is a need to go from information resource to GRDDL
> > results -- the problem is that it *fails* to define results 
> in terms of
> > representations.
> > 
> > Here are some places in the spec where this problem shows up:
> > http://www.w3.org/TR/grddl/#rule_result
> > http://www.w3.org/TR/grddl/#rule_merge
> > http://www.w3.org/TR/grddl/#rule_rdfxbase
> > http://www.w3.org/TR/grddl/#rule_profiletrans
> > http://www.w3.org/TR/grddl/#rule_txprop
> > http://www.w3.org/TR/grddl/#GRDDL_aware_agent
> > http://www.w3.org/TR/grddl/#agt_obl
> > 
> > These should be relatively easy to fix.  In fact, quite 
> tellingly, some
> > of the normative rules define a variable for a posited "information
> > resource" but never reference that variable.
> > 
> > Lest anyone assert that this pipeline use case is outside 
> the WG's scope
> > because it isn't reflected in the GRDDL use cases document, 
> I will note
> > that:
> > 
> >  - The GRDDL use cases document contains *many* aspects of problem
> > context that nobody intends to become a part of the spec.
> > 
> >  - The use of information resources in the use cases document seemed
> > quite natural to me, as part of the *context*, and hence I 
> did not see
> > any problem with the use cases document when I reviewed 
> that earlier.
> > 
> >  - It seemed obvious to me that GRDDL would be used to define the
> > semantics of individual *representations*, since one can 
> only really be
> > sure of the semantics of a particular representation.
> > 
> >  - It *always* makes sense to talk about the GRDDL results of a
> > particular representation; it does not always make sense to 
> talk about
> > the GRDDL results of an information resource.
> > 
> >  - The GRDDL use cases document does in fact have a wiki 
> example, and
> > since wiki content often changes, that is a good example of 
> the need for
> > GRDDL results to reflect the semantics of a particular 
> *representation*
> > rather than an information resource in general.
> > 
> > BTW, I would be happy to join the teleconference (if 
> invited) to further
> > explain and answer questions if you think that would be helpful.
> > 
> > Again, thanks for all your work on this, and please let me 
> know how I
> > can be most useful in helping to resolve this issue.
> > 
> > Thanks
> > 
> > David Booth, Ph.D.
> > HP Software
> > +1 617 629 8881 office  |  dbooth@hp.com
> > http://www.hp.com/go/software
> 
> -- 
> Hewlett-Packard Limited
> registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> 
Received on Friday, 15 June 2007 20:57:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:43 GMT