Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xsd:dateTime less than operator issue #630

Closed
wrobell opened this issue May 11, 2016 · 2 comments
Closed

xsd:dateTime less than operator issue #630

wrobell opened this issue May 11, 2016 · 2 comments
Labels
bug Something isn't working SPARQL
Milestone

Comments

@wrobell
Copy link

wrobell commented May 11, 2016

Filters on xsd:dateTime work with literals, i.e.

FILTER(?start > "2016-01-01 20:01"^^xsd:dateTime)

But if there are two variables of xsd:dateTime then filter does not work properly, i.e.

FILTER(?start < ?end)

Script illustrating the issue below. It should show c1 and c2 entities, but nothing is shown instead.

from pprint import pprint
import rdflib
import io

data = """
@prefix : <#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

:C a rdfs:Class.

:start a rdf:Property;
    rdfs:domain :C; 
    rdfs:range xsd:dateTime.

:end a rdf:Property;
    rdfs:domain :C; 
    rdfs:range xsd:dateTime.

:c1 a :C;
    :start "2016-01-01 20:00:00"^^xsd:dateTime;
    :end "2016-01-02 20:01:00"^^xsd:dateTime.

:c2 a :C;
    :start "2016-01-01 20:05:00"^^xsd:dateTime;
    :end "2016-01-01 20:30:00"^^xsd:dateTime.
"""

graph = rdflib.Graph()

f = io.StringIO(data)
graph.parse(f, format='n3')

result = graph.query("""
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?c
WHERE {
    ?c :start ?start;
        :end ?end.
#    FILTER(?start > "2016-01-01 20:01"^^xsd:dateTime)   # this works!
    FILTER(?start < ?end)
}
""")

pprint(list(result))
@joernhees joernhees added this to the rdflib 4.2.2 milestone May 12, 2016
@joernhees joernhees added bug Something isn't working SPARQL labels May 12, 2016
@colinfang
Copy link

Equality operator doesn't work either.

g2 = rdflib.Graph()
literal_date = Literal(datetime.date(2016,1,1), datatype=XSD.date)
print g2.serialize(format="n3")
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<1> <1> "2016-01-01"^^xsd:date .

q = """
    Ask {
        ?x ?x ?dt .
        FILTER (?dt = ?dt2) .
    }
    """
res = g2.query(
    q, initBindings={
        'dt2': literal_date
    }
).askAnswer
res

False

@gromgull
Copy link
Member

Your first case, the problem is that your datetime syntax is wrong, if you change it to:

    :c1 a :C;
        :start "2016-01-01T20:00:00"^^xsd:dateTime;
        :end "2016-01-02T20:01:00"^^xsd:dateTime.

    :c2 a :C;
        :start "2016-01-01T20:05:00"^^xsd:dateTime;
        :end "2016-01-01T20:30:00"^^xsd:dateTime.

it works.

The second problem is #615

tgbugs added a commit to tgbugs/rdflib that referenced this issue Nov 30, 2017
This commit provides basic infrastructure for sorting Literals by value
where the underlying type has no total ordering. This provides a more
consistent solution to issues like:
RDFLib#648,
RDFLib#630, and
RDFLib#613. Where workarounds are
implemented in the serializer. This leads to massively increased code
complexity in the serializers to compensate for the fact that Literal
do not support a total ordering because of some of the underlying python
datatypes do not. The only datatype that I know of that causes this
issue at the moment is datetime, and I have implemented a fix for that.

If other types are found to have this issue the solution is to add
an entry to _NO_TOTAL_ORDER_TYPES that includes a function that
partitions the type into subtypes that do have total orders.
tgbugs added a commit to tgbugs/rdflib that referenced this issue Nov 30, 2017
This commit provides basic infrastructure for sorting Literals by value
where the underlying type has no total ordering. This provides a more
consistent solution to issues like:
RDFLib#648,
RDFLib#630, and
RDFLib#613. Where workarounds are
implemented in the serializer. This leads to massively increased code
complexity in the serializers to compensate for the fact that Literal
do not support a total ordering because of some of the underlying python
datatypes do not. The only datatype that I know of that causes this
issue at the moment is datetime, and I have implemented a fix for that.

If other types are found to have this issue the solution is to add
an entry to _NO_TOTAL_ORDER_TYPES that includes a function that
partitions the type into subtypes that do have total orders.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working SPARQL
Projects
None yet
Development

No branches or pull requests

4 participants