Upgrading from RDFLib version 3.X to 4.X¶
RDFLib version 4.0 introduced a small number of backwards compatible changes that you should know about when porting code from version 3 or earlier.
SPARQL and SPARQLStore are now included in core¶
For version 4.0 we’ve merged the SPARQL implementation from
rdflib-sparql, the SPARQL(Update)Store from
rdflib-sparqlstore and miscellaneous utilities from
rdfextras. If you used any of these previously, everything you need should now be included.
We separate lexical and value space operations for datatyped literals.
This mainly affects the way datatyped literals are compared. Lexical space comparisons are done by default for
!=, meaning the exact lexical representation and the exact data-types have to match for literals to be equal. Value space comparisons are also available through the
< > <= >= are also done in value space.
Most things now work in a fairly sane and sensible way, if you do not have existing stores/intermediate stored sorted lists, or hash-dependent something-or-other, you should be good to go.
Things to watch out for:
Literals no longer compare equal across data-types with
>>> Literal(2, datatype=XSD.int) == Literal(2, datatype=XSD.float) False
But a new method
rdflib.term.Identifier.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
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,
plain literals both map to strings and compare fine, but:
>>> Literal(2, datatype=XSD.int).eq(Literal('2')) False
Literals will be normalised according to datatype¶
If you care about the exact lexical representation of a literal, and not just the value. Either set
False before creating your literal, or pass
normalize=False to the Literal constructor
Ordering of literals and nodes has changed¶
Comparing literals with
<, >, <=, >= now work same as in SPARQL filter expressions.
Greater-than/less-than ordering comparisons are also done in value space, when compatible datatypes are used.
Incompatible datatypes are ordered by data-type, or by lang-tag.
For other nodes the ordering is
None < BNode < URIRef < Literal
Any comparison with non-rdflib Node are
In PY2.X some stable order will be made up by python.
In PY3 this is an error.
Custom mapping of datatypes to python objects¶
You can add new mappings of datatype URIs to python objects using the
This also allows you to specify a constructor for constructing objects from the lexical string representation, and a serialization method for generating a lexical string representation from an object.
rdflib.namespace.Namespaceis no longer a sub-class of
rdflib.term.URIRefthis was changed as it makes no sense for a namespace to be a node in a graph, and was causing numerous bug. Unless you do something very special, you should not notice this change.
The identifiers for Graphs are now converted to URIRefs if they are not a
rdflib.term.Node, i.e. no more graphs with string identifiers. Again, unless you do something quite unusual, you should not notice.
String concatenation with URIRefs now returns URIRefs, not strings:
>>> URIRef("http://example.org/people/") + "Bill"
This is be convenient, but may cause trouble if you expected a string.