W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: htmldata-ISSUE-2 (Use of rdf:XMLLiteral): Should Microdata-RDF generate XMLLiteral values [Microdata to RDF]

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Fri, 21 Oct 2011 13:51:56 -0400
To: Philip Jägenstedt <philipj@opera.com>
CC: HTML Data Task Force WG <public-html-data-tf@w3.org>
Message-ID: <2CAE994B-EDAA-40E8-9E6E-BB39F6ED8A66@greggkellogg.net>
On Oct 21, 2011, at 1:55 AM, Philip Jägenstedt wrote:

> On Thu, 20 Oct 2011 20:42:32 +0200, HTML Data Task Force Issue Tracker  
> <sysbot+tracker@w3.org> wrote:
> 
>> Should the Microdata to RDF spec parallel RDFa and generate an  
>> rdf:XMLLiteral in this case?
> 
> I'd say no. XML is not part of the microdata model, and it would be very  
> bad indeed if some toolchains saw this as plain text while others saw it  
> as a DOM fragment.

The data model would be that of either a plain or a typed literal. In RDFa, an rdf:XMLLiteral is a serialization of the element's node-set using Exclusive Canonical XML, which could be created from the DOM fragment. In fact, this is what conformant HTML+RDFa processors already must do. This would also leave open the question about recursing into the element to extract further MD properties, as RDFa 1.1 does, but RDFa 1.0 did not.

As with most things now, this would likely be described as a processor option, which could be triggered by the use of specific types or vocabulary definitions. For example, if the range of a property includes rdf:XMLLiteral, it would seem to be appropriate.

As for a hypothetical rdf:HTMLLiteral, perhaps the RDF WG will come up with an similar recommendation that is, but we can't really proceed until that comes about.

Regarding different interpretations by tool chains, given that we seem to be going to a parameterized transformation algorithm, this would be only one area where different tools might generate different results. I'd rather see us come up with unambiguous transformation rules that did not rely on the state of different provided to a parser, but that might need to be left to another group that would take on this work at the end of the TF.

> If there are good reasons to extend the microdata model,  
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13468 would be a starting  
> point, it is currently closed as NEEDSINFO.

Looking at the issue, it seems that all the good arguments have been laid out, and I don't see much more to add. It seems convincing to me that some vocabularies have a legitimate need to be able to capture markup in addition to the text content; it may be that the TF recommendation for these use cases is to use RDFa instead of Microdata.

> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software

Gregg
Received on Friday, 21 October 2011 18:19:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 October 2011 18:19:13 GMT