Literal reworking

Between version 3.4.0 and 4.0, a backwards incompatible change was made in RDFLib to how datatyped literals are handled.

Hopefully, the changes will not affect very many users of RDFLib, but this page outlines what was changed and collects any changes required in code using RDFLib.

Why were backwards incomaptible changes introduced?

The by far biggest problem was that in the pre 4.0 handling of Datatyped Literals, __hash__ and __eq___ were not consistent, i.e.

What is new?

All comparisons methods for literals have been reworking to be in line with the SPARQL 1.1 spec, i.e.:

• Node equality according to __eq__ / == are done according to:

• Relative comparisons (>, <, >=, <= operators / __lt__, __gt__, __ge__, __le__ methods and therefore sort-ordering of Nodes is done according to http://www.w3.org/TR/sparql11-query/#modOrderBy

What do I have to watch out for?

Literals no longer compare equal across data-types with ==

i.e.

>>> Literal(2, datatype=XSD.int) == Literal(2, datatype=XSD.float)
False

But a new method eq on all Nodes has been introduced, which does semantic equality checking, i.e.:

>>> Literal(2, datatype=XSD.int).eq(Literal(2, datatype=XSD.float))
True

The eq method is still limited to what data-types map to the same value space, i.e. all numeric types map to numbers and will compare, xsd:string and plain literals both map to strings and compare fine, but:

>>> Literal(2, datatype=XSD.int).eq(Literal('2'))
False

Custom mapping of datatypes to python objects

You can add new mappings of datatype URIs to python objects using the rdflib.term.bind method. This also allows you to specify a constructor for constructing objects from the lexical string representation, and a serialisation method for generating a lexical string representation from an object.