- From: Bob DuCharme <bob@snee.com>
- Date: Wed, 25 Oct 2006 14:37:24 -0400 (EDT)
- To: public-grddl-comments@w3.org
Two points and a question based on them:
- In use case 3 (http://www.w3.org/TR/grddl-scenarios/#guitar_use_case),
"Reviews published using hReview microformats can be discovered using
existing search services. These source documents can be consumed by a
GRDDL-aware agent to extract the RDF which is then aggregated together in
a store."
- A GRDDL-aware agent is defined as "a software agent able to identify the
GRDDL transformations specified in a source document and run them to
extract RDF."
So it looks like the guitar reviews are supposed to specify the
transformations to run on them if you want to extract their data as RDF,
i.e. that they have a http://www.w3.org/2003/g/data-view#transformation
attribute on their root element, or, more likely, a
link[@rel='transformation'] element for the special case of XHTML, which
doesn't like attributes from foreign namespaces.
What about specifying a GRDDL transformation for a document that has
neither, and which we can't edit? The ability to convert output of web
services to RDF, for example, opens up a lot of possibilities, but we
don't want to have to wait for Amazon to add an
http://www.w3.org/2003/g/data-view#transformation attribute to the
ProductInfo element returned by their web service (or adding a
grddl:namespaceTransformation property to a namespace document) before
incorporating that data into an app.
Would it make sense to do just have a small element with a
grddl:transformation attribute on the root and an xi:include element
pointing at the actual document to transform, like this?
<someContainer xmlns:grddl="http://www.w3.org/2003/g/data-view#"
xmlns:xi="http://www.w3.org/2001/XInclude"
grddl:transformation="http://www.snee.com/xsl/xml2rdf.xsl">
<xi:include
href="http://xml.amazon.com/onca/xml3?t=idname&dev-t=devtoken&ArtistSearch=The%20Velvet%20Underground&mode=music&type=heavy&f=xml"/>
</someContainer>
I suppose that XInclude support isn't quite where we want it, and I wonder
if alternative ideas to address the same issue have been floated.
thanks,
Bob
Received on Wednesday, 25 October 2006 18:37:37 UTC