RDFLib/rdflib — pull request #255 by gromgull (2013-03-06 15:58:34+00:00)
Title: Literal reworking

I have implemented the changes that me and Joern discussed previously and presented in #196 (https://github.com/RDFLib/rdflib/issues/196#issuecomment-10733279)

The status is well described in the doc-string for the Literal class:

https://github.com/RDFLib/rdflib/blob/literal_reworking/rdflib/term.py#L398

and for __gt__

https://github.com/RDFLib/rdflib/blob/literal_reworking/rdflib/term.py#L689

The highlights:
* Literal __eq__ and __hash__ are done in lexical space.
* Literal lexical forms are preserved if the NORMALIZE_LITERALS flag is set to False.
* but if the NORMALIZE_LITERALS flag is set to True, __eq__, __hash__ will effectively work in value space for the given datatype.

* A new method .eq is available for all RDFLib Nodes, this does semantic equivalence, i.e. comparisons in value space for literals. This follows SPARQL rules for the = operator.

* The rich comparison methods __gt__, etc. also follow collation rules as set down by SPARQL. The greater/lesser OR equal methods use eq (not __eq__)

* The old equivalence between basic python types and literals are GONE, if you really need this, use literal.value

Of course this branch still passes all tests. I would hope that few people relied on the python-type/literal comparisons before, and hopefully these changes should not break much in any project using rdflib.

Also, with this branch, the rdflib-literalfix branch of rdflib-sparql passes all the sparql11 tests regarding literal handling.

I think this is a principles and even slightly sensible solution. If I do not hear/see any very good objections I will merge into master in the next few days.