- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Sun, 17 Dec 2006 22:44:15 -0500
- To: Ben Adida <ben@adida.net>
- Cc: Murray Maloney <murray@muzmo.com>, public-grddl-wg@w3.org
As regards our scope and charter, note that a relationship with RDFa is definitely part of our charter [1]. In particular: "tutorial materials and use cases sufficient to bootstrap adoption of GRDDL"..."with popular XHTML dialects such as the Dublin Core XHTML profile and microformats such as hCalendar and hCard as well as newer work such as RDFa and Embedded RDF" Now, we have also, although the issue is not formally resolved, currently defined the output of GRDDL in terms of an abstract graph as opposed to RDF syntax. In that regard, the door of a GRDDL that transforms HTML -> HTML+RDFa (with the RDFa being a valid graph) is still wide open. Ben Adida wrote: > Murray, > > Yes, I agree that that is the appropriate output. But I have to point > out that this WG ruled out of scope the "hGRDDL transformation" proposal > I made at the very beginning. > > So, RDFa is definitely not out of scope, although the particulars of hGRDDL do need implementing. Could we get a hGRDDL test-case or at least example? > Here's what I wanted to see: > > 1) an RDFa-aware browser sees the profile and locates the corresponding > HTML->HTML+RDFa transformation, GRDDL style. > In fact, with GRDDL designed to work with the namespace document to extract GRDDL transformations, it seems all one would have to do would be to put a GRDDL from XHTML2 -> RDF/a + XHTML2 in the XHTML2 namespace. Writing that XSLT would probably be a task well-regulated to either BenA or Fabien, of if you're too busy, to someone in the SWD WG that is well-versed in RDFa. > 2) the transformation is performed inline on the DOM of the page, > yielding proper HTML+RDFa with appropriately updated RELs and CLASSes > that were specified by the profile transformations. This transformed > HTML can be rendered normally. > I don't see how this is a problem per se, although this step (displaying the HTMLwith RDFa normally) would have to be done in the client browser and is not really part of GRDDL. Should not be too hard to add this to an existing open source browser as a plug-in. It's a good use-case, one that we have included in our use-cases document [2]: "To enable this copy-paste, Jane's browser includes a GRDDL-aware agent and supports a default RDF-in-HTML embedding scheme called RDFa. The GRDDL transformation specified in the page indicates how to transform this XHTML into XHTML+RDFa, while preserving the style and layout of the page. Thus, Jane's RDFa-aware browser can perform the transform even before rendering the XHTML." > 3) the updated, rendered page can be parsed using the normal RDFa, > yielding RDF attached to their corresponding DOM nodes. > > This also enables microformats to be transformed to RDFa, which is > fantastic for all involved. > > The big issue to resolve is (1). How do I request the appropriate > HTML->HTML+RDFa transformation? Is there some content negotiation, or > some other clever trick, to determine which transformation I want to > use? How do I handle the case of multiple profiles? One after the other? > In which order? > The multiple profile issue, which I think we need a good test-case for (unless we already have one!) is not too difficult. I believe the current story with multiple profiles that people seem most happy with (although I'm happy to add this to the agenda for the next meeting for further discussion) would be that *all the transforms* are run against the source document, and then the final result graph is the merge of all the graphs produced by the transforms. > So yeah, in theory I agree, but with these issues judged out of scope, > the RDFa group is stuck trying to figure out how to make this happen. > Again, it's not out of scope. What's needed is for people from an RDFa background to write this transform and test case. We even will link to it explicitly from our use case document, as can be seen from the "See also: put projects and prototypes here." under Use Case 1. However, we do need this to be done before pretty soon, as we are slated to go to Last Call within a month or two and I'd like all the @@TODOs in the various specs to be done before going to Last Call. > With GRDDL, we can certainly take it straight from HTML to RDF, but then > we lose the rendered-HTML/RDF correspondence that RDFa strives to maintain. > That's just a tricky XSLT transform, but is there reason to believe this transform cannot be written? While it is intimidating, I imagine some sort of XSLT expert could write one that more or less puts the RDF "inline" without losing the HTML content. If not, we need to know up front or possibly use another transform language that XSLT that makes this easier. - and the GRDDL spec leaves this door open as well. So should we add this to next week's agenda and try to get an action item to write a hGRDDL and a test case? > -Ben > > [1]http://www.w3.org/2006/07/grddl-charter.html [2]http://www.w3.org/TR/grddl-scenarios/ -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Monday, 18 December 2006 03:44:37 UTC