Re: Clarifying CURIEs [was Re: RDFa - Dublin Core Metadata - [Fwd: Draft of revised version of Expressing DC in X/HTML meta/link elements]]

Hi Ben,

from an abstract, specification point of view I like the approach. Yes,
it makes the core RDFa approach much cleaner and that is a great plus.

I does raise some questions on the implementation side, though. The
problem is that GRDDL transforms are usually XSLT based, and I would
expect that do would hGRDDL. I am not sure how this would/should work
well with an implementation like, for example, pyRdfa.

I am back at home for a week (go to Singapore coming week end) but I
might have some time to experiment with some architecture on pyRdfa that
would be based on such pre-processor transformations first. But it looks
pretty complicated to use pyRdfa to spawn off an arbitrary XSLT
transform and pick up the results easily. Of course, it is easier to
write transformations in Python and have an architecture that makes such
transformations 'inside' (I will definitely do that to experiment with).
Which means that one would have to re-implement those transformations in
Python.

Can you refer to your hCard and hCalendar transforms to re-simulate them?

Ivan

Ben Adida wrote:
> 
> Ivan wrote, regarding the CURIE spec:
>> However. We clearly would need proper TF resolution on these issues.
> 
> We have agreed (though not quite resolved) to include a complete CURIE
> description in the RDFa Syntax document. See [1].
> 
> Mark wrote:
>> All of this could be done in a preprocessing step which might just be
>> Ben's hGRDDL proposal from before.
> 
> Exactly, and in fact *all* of this can and should be handled with
> hGRDDL. For those who don't know what I'm talking about, the point of
> the hGRDDL proposal is:
> 
> GRDDL takes XHTML and outputs RDF/XML
> 
> while
> 
> hGRDDL takes XHTML and outputs XHTML+RDFa.
> 
> So hGRDDL would take XHTML with DC markup, and, using a transform
> specified by the DC profile, sprinkle in the proper RDFa with the right
> syntax. For example, DC's example #1 would be processed as follows
> 
> (note that I moved @profile from the HTML element to HEAD... I think
> they made a mistake?)
> 
> ======
> <html xmlns="http://www.w3.org/1999/xhtml">
>   <head profile="http://dublincore.org/documents/2007/07/27/dc-html/">
>     <title>Services to Government</title>
>     <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
>     <link rel="DCTERMS.subject" href="http://example.org/topics/archives" />
>   </head>
> ======
> 
> The dc-html profile should specify both a GRDDL and an hGRDDL transform.
> 
> The hGRDDL transform modifies the DOM as follows:
> 
> ======
> <html xmlns="http://www.w3.org/1999/xhtml">
>   <head xmlns:dcterms="http://purl.org/dc/terms/">
>     <title>Services to Government</title>
>     <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
>     <link rel="DCTERMS.subject dcterms:subject"
> href="http://example.org/topics/archives" />
>   </head>
> ======
> 
> (Note specifically the addition of the namespace and the @rel value of
> dcterms:subject.)
> 
> I've written up a paper about this which should see the light of day
> soon, and which I think will be crucial to link other syntaxes with RDFa
> without making RDFa a hodge-podge of different syntaxes.
> 
> (And it's worth noting that I've implemented hGRDDL for hCard and
> hCalendar, and it works surprisingly well with very little code.)
> 
> In other words, I think we can ignore this for now: we'll have a proper
> solution by transforming legacy syntaxes, rather than supporting them in
> RDFa core.
> 
> -Ben
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Jul/0116
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 20 August 2007 13:15:25 UTC