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

<time> and <data> support in RDFa and implications for Microdata

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Thu, 17 Nov 2011 12:14:45 -0500
To: HTML Data Task Force WG <public-html-data-tf@w3.org>
Message-ID: <8BDF534C-C503-41E8-81B7-9DD9700B8533@greggkellogg.net>
In today's RDFWA telecon [1], we added specific support for <time> and <data> pretty much as we have agreed for Microdata to RDF.

For <time>, it was decided that, if there is no lexical match on an appropriate XSD datatype, that it would create a plain literal inheriting the element's language. The rational for this was that a textual description of a time really needs to appropriate language context to understand. For example:

	Thu, 17 Nov 2011 15:13:39 GMT

makes sense in English, and maybe some other languages, but might not be universally valid. For this reason, it was decided to keep language if a plain literal is created. I suggest we do the same in Microdata to RDF.

Similar logic for the <data> element, to keep the language. There was some feeling that the intention of this element is to provide a machine-readable representation, but that the HTML5 spec provides no micro-syntax for interpreting values. In the absence of this, providing "magic" datatype matching could do more harm than good. Given this, the language of the element could also be important in determining author's meaning.

For HTML5 members, has there been any discussion on providing a micro-syntax for <data> values? If it's intended to be machine-readable, how exactly is a processor to interpret the meaning?

For both <time> and <data>, the RDFWA WG decided to re-visit the issue if the HTML5 WG either extends the data model (in the case of <time>), or adds clarity to appropriate datatype matching for <data>.


[1] http://www.w3.org/2010/02/rdfa/meetings/2011-11-17
Received on Thursday, 17 November 2011 17:15:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:06 UTC