Fwd: Plain vs. xsd:string literals in RDFa

Forwarding Gregg's message to the list – he's not a member so his mail bounced.


Begin forwarded message:

> From: Gregg Kellogg <gregg@kellogg-assoc.com>
> Date: 23 August 2011 19:47:12 GMT+01:00
> To: Richard Cyganiak <richard@cyganiak.de>
> Cc: Gregg Kellogg <gregg@kellogg-assoc.com>, W3C RDFWA WG <public-rdfa-wg@w3.org>, RDF Working Group WG <public-rdf-wg@w3.org>
> Subject: Re: Plain vs. xsd:string literals in RDFa
> 
> On Aug 23, 2011, at 3:57 AM, Richard Cyganiak wrote:
> 
>>> 	• 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.
>> 
>> I have trouble making sense of the paragraphs above, I find it hard to follow what you mean by “producing” and “outputting”. Could you perhaps re-state this with an example?
> 
> From what you've said, it sounds like the issue is if the underlying data model is RDF 2004 or RDF 1.1. If Raptor were still RDF 2004, then an RDFa 1.1 processor treating "abc" as "abc"^^xsd:string would cause an existing RDF/XML implementation to serialize with an @datatype. Consider the following, read by a conforming RDF 1.1 Turtle processor:
> 
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> :a :b "abc"
> 
> This would result in the following triple in a RDF 1.1 data model (abstract syntax, I realize that the datatype should be eliminated for a concrete serialization):
> 
> <http://example.com#a> <http://example.com#b> "abc"^^<http://www.w3.org/2001/XMLSchema#string> .
> 
> When this is serialized with an RDF/XML serializer using existing semantics:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF xmlns="http://example.com#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:base="http://example.com">
>   <rdf:Description rdf:about="#a">
>     <b rdf:datatype="http://www.w3.org/2001/XMLSchema#string">abc</b>
>   </rdf:Description>
> </rdf:RDF>
> 
> I'm not sure how this could be different, unless RDF/XML (and indeed Notation3, TriX, TriG, …) were updated as well.
> 
> So, if librdfa is updated in Raptor without corresponding changes in all other serializers, It will lead to serialized output in other forms that includes datatypes where none existed earlier.
> 
> In my case, I would update all my parsers and serializers (including my RDFa serializer, so there is at least one) to not include the datatype markup for xsd:string, but this might not hold for other libraries that aren't as closely managed.
> 
> Thanks, we'll discuss in the RDFWA WG call on Thursday.
> 
> Gregg
> 
> (Note, my reply to RDF WG may bounce, so someone may need to re-post).
>