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

rdflib.Graph.query does not enforce Aggregate Projection Restrictions #2960

Open
lu-pl opened this issue Oct 29, 2024 · 0 comments
Open

rdflib.Graph.query does not enforce Aggregate Projection Restrictions #2960

lu-pl opened this issue Oct 29, 2024 · 0 comments

Comments

@lu-pl
Copy link
Contributor

lu-pl commented Oct 29, 2024

rdflib.Graph.query does not enforce Aggregate Projection Restrictions.

E.g. the following

query = """
select (count(*) as ?cnt) ?parent ?child ?name
where {
    values (?parent ?child ?name) {
        ('x' 'c' 'foo')
        ('y' 'd' UNDEF)
        ('y' 'e' UNDEF)
        ('z' UNDEF UNDEF)
    }
}
"""

graph = Graph()
result = graph.query(query)
result.bindings

is invalid SPARQL according to Aggregate Projection Restrictions:

In a query level which uses aggregates, only expressions consisting of aggregates and constants may be projected, with one exception. When GROUP BY is given with one or more simple expressions consisting of just a variable, those variables may be projected from the level.

Yet the above code results in

[
    {
        rdflib.term.Variable("parent"): rdflib.term.Literal("x"),
        rdflib.term.Variable("child"): rdflib.term.Literal("c"),
        rdflib.term.Variable("name"): rdflib.term.Literal("foo"),
        rdflib.term.Variable("cnt"): rdflib.term.Literal(
            "4", datatype=rdflib.term.URIRef("http://www.w3.org/2001/XMLSchema#integer")
        ),
    }
]

Blazegraph and GraphDB reject the query with Malformed Query exceptions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@lu-pl and others