W3C home > Mailing lists > Public > public-grddl-wg@w3.org > December 2006

Re: Review of testlist1#rdfa1

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Sun, 17 Dec 2006 22:44:15 -0500
Message-ID: <45860E8F.2020407@ibiblio.org>
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
> 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


Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426
Received on Monday, 18 December 2006 03:44:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:09 UTC