We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Please advise if Sparqlify is capable for query rewriting without graph materialization?
I am looking for a way to translate the following SPARQL query ...
SELECT ?interface ?ip WHERE { ?interface network:hasIpAddress ?ip. ?ip network:containedWithin "192.168.1.0/24". }
or, alternatively:
SELECT ?interface ?ip WHERE { ?interface network:hasIpAddress ?ip. FILTER(?ip IN "192.168.1.0/24"). }
... to the following SQL query:
SELECT interface, ip FROM interfaces WHERE ip_address << "192.168.1.0/24"
"<<=" operator in SQL WHERE statement is specific to PostgreSQL type "inet": https://www.postgresql.org/docs/9.3/functions-net.html
For a general case, "192.168.1.0/24" may be considered as parameter that must be passed down from SPARQL to SQL for handling without materialization.
I would be grateful if you could suggest alternatives if it is not possible with Sparqlify.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Please advise if Sparqlify is capable for query rewriting without graph materialization?
I am looking for a way to translate the following SPARQL query ...
SELECT ?interface ?ip
WHERE {
?interface network:hasIpAddress ?ip.
?ip network:containedWithin "192.168.1.0/24".
}
or, alternatively:
SELECT ?interface ?ip WHERE {
?interface network:hasIpAddress ?ip.
FILTER(?ip IN "192.168.1.0/24").
}
... to the following SQL query:
SELECT interface, ip
FROM interfaces
WHERE ip_address << "192.168.1.0/24"
"<<=" operator in SQL WHERE statement is specific to PostgreSQL type "inet": https://www.postgresql.org/docs/9.3/functions-net.html
For a general case, "192.168.1.0/24" may be considered as parameter that must be passed down from SPARQL to SQL for handling without materialization.
I would be grateful if you could suggest alternatives if it is not possible with Sparqlify.
The text was updated successfully, but these errors were encountered: