(This is the only feature that I have _not_ implemented, because some design decisions are to be made...)
http://www.w3.org/TR/2012/rdf11-concepts/#section-Graph-Literal
This is the only not-entirely-backward-compatible change in RDF 1.1. Essentially, _all_ literals have a type now. If a literal does not have a language tag attached, then it is xsd:string; if there _is_ a language tag, that a new datatype is used, rdf:langString. Ie, gone are the former plain literals.
Serializations are allowed to provide syntactic shortcuts for xsd:string; ie, the old
:a :b "blabla" .
remains valid, but it is equivalent to
:a :b "blabla"^^xsd:string .
Also
:a :b "blabla"@en .
which would generate a literal of type rdf:langString and with language tag 'en'. There is no special syntax whereby one could use rdf:langString explicitly in, say, turtle.
An implementation strategy in RDFLib for this seems to be relatively straightforward:
- the __new__ method for RDFLib could be modified to store the right datatype attribute value for the literal: if a lang is given, then it is rdf:langString, if it is without any literal and language tag, then it is set to xsd:string.
- the _literal_n3 method should be modified to react separately to langString and to xsd:string, generating the usual shortcuts. As far as I could see, the turtle serialization uses that.
- the nt serializer has to be modified (in _quote_literal) to generate the two possible shortcuts. Something similar for nquads (although I have not really checked that one)
- the rdf/xml serializer has to be modified accordingly in the predicate method
(- whoever does a json-ld serializer should also make the necessary changes)
All this is relatively straightforward, but the issue is twofolds:
- a, for example, turtle -> rdflib -> turtle is not exactly roundtripping any more; indeed, if the incoming turtle includes an explicit xsd:string datatyped literal, that will disappear at the output. Although the graphs are equivalent, some people may not like that.
- it is not backward compatible, ie, clients may inquire for datatypes and the result will always return one, in contrast to RDF 1.0. It is a bit unclear what we should do about this; should we include some sort of a RDF 1.1 flag that people can use to set which version of the library they want to use?
Because the outcome of these two bullet point may heavily influence the way all this implemented, I decided not to those changes (and the changes are spread over many files...)
Thoughts?
Ivan
----
Ivan Herman
4, rue Beauvallon, clos St Joseph
13090 Aix-en-Provence
France
http://www.ivan-herman.net