W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2011

Plain vs. xsd:string literals in RDFa

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 22 Aug 2011 18:18:42 -0400
To: Richard Cyganiak <richard@cyganiak.de>
CC: W3C RDFWA WG <public-rdfa-wg@w3.org>
Message-ID: <EE482946-CCEE-4E4F-BF5D-6FFE8C997787@greggkellogg.net>
Richard, on today's RDF Web Apps WG call we discussed the implications of the RDF WG's decision to collapse Plain Literals with xsd:string typed literals, and the implications for RDFa. Concerns were raised about backwards compatibility issues and the effect on the RDF(a) API when providing triples through a call-back, which is nominally a representation of the abstract syntax. This is expressed in ISSUE-101 [1]

These are the specific issues we're considering:

 1.  Should RDFa Processors generate "foo"^^xsd:string from now on, or just the plain literal?
 2.  Should the RDFa API callback produce a "foo" property with an "xsd:string" datatype, or just a "foo" plain literal property? Note that this is not a serialization, so the rules about not using xsd:string markup might not apply
 3.  If we must produce an "xsd:string", how should we handle the case where something like Raptor is using a library that uses the new "foo"^^xsd:string form, with a library that thinks there is a difference between xsd:string and a plain literal? Case in point, Raptor uses librdfa and could output to RDF/XML. Something that used to be output as a plain literal will now be output as an xsd:string, which will inevitably break code. Is this fine?

>From my understanding, we could choose either to represent both plain literals and xsd:string typed literals using either an un-datatyped literal, or a typed literal [2].

One of the concerns is the behavior of existing libraries, which currently do differentiate between these different forms. Also, for other languages (e.g. RDF/XML) which are not likely to be updated with this requirement. This could lead to inconsistent behavior between languages and implementations.

Changing RDFa to generate xsd:string typed literals would be a backwards-incompatible change, and backends or APIs which were previously expecting a literal without a datatype would know be faced with those literals having a datatype.

The group would like some guidance on this issue, and wondered if you or the RDF WG might address some of these issues and provide some guidance.

Gregg

[1] http://www.w3.org/2010/02/rdfa/track/issues/101
[2] http://www.w3.org/2011/rdf-wg/wiki/StringLiterals/AbolishUntaggedPlain
Received on Monday, 22 August 2011 22:19:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:52 UTC