Re: subtypes of xsd:string

There will be some effects on implementations; not serious but non zero. I, sort of, ran through in my head what RDFLib should do (being a python user):

1. Literal objects, when initialized language, the datatype attribute should be set to the rdf:Text (or whatever that will be) (currently set to None)
2. Literal objects, when initialized without language, the datatype attribute should be set to the xsd:string (currently set to None)
3. Some checks have to be changed (the current implementation sets the lang attribute to none if a datatype is provided, but that should not happen if the object initialization gets rdf:Text)
4. The comparison operator should be modified
5. All serializers should modify their behaviour: at the moment, when they see a datatype, they simply produce "..."^datatype. This would still be fine with xsd:string if that is allowed but, according to the proposal, this should _not_ happen with rdf:Text. Ie, all serializers must have an extra branch to handle this case.

Nothing hugely complicated, but does require some work. I foresee #5 to be the most complicated in practice, due to the plugin architecture RDFLib has (meaning that applications may have their own serializers). I guess all other RDF environment will have to perform roughly the same steps.

I.

On May 25, 2011, at 11:26 , Richard Cyganiak wrote:

> On 25 May 2011, at 00:46, Jeremy Carroll wrote:
>> it may be odd if we effectively deprecate xsd:string for RDF (surface syntax ...) but still have subtypes lying around ...
> 
> The proposal does not call for the deprecation (effective or not) of xsd:string.
> 
> The proposal is to remove plain literals from the abstract syntax.
> 
> In concrete syntaxes, both "foo" and "foo"^^xsd:string forms would still be allowed. The former would be syntactic sugar, just like 1 and "1"^^xsd:integer in Turtle.
> 
> There should be some language to the effect that "foo" is preferred, simply for ergonomic reasons. I phrased this as a SHOULD in the proposal. Weaker language might be sufficient in the general case. Or maybe expressing this preference is altogether unnecessary.
> 
> Some syntaxes have use cases that are hampered by the variability introduced by syntactic sugar. N-Triples and SPARQL Results XML/JSON, mostly. I think these syntaxes should make a stronger statement in their respective syntax spec. Perhaps forbid one of the forms when serializing. Which one doesn't really matter.
> 
> Best,
> Richard


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

Received on Wednesday, 25 May 2011 09:48:17 UTC