add(feature): RDF1.2/SPARQL1.2 TripleTerm.#151
Conversation
|
Performance Impact: For workloads that do not involve tripleterms, there is theoretically virtually no impact. Ongoing Effort: The SPARQL parser is currently handwritten in C++. I am currently attempting to refactor the parser using ANTLR4 grammar. |
| var : VAR1 | VAR2 ; | ||
| graphTerm : iri | rDFLiteral | numericLiteral | booleanLiteral | blankNode | NIL ; | ||
| graphTerm : iri | rDFLiteral | numericLiteral | booleanLiteral | blankNode | NIL | tripleTerm ; | ||
| tripleTerm : TRIPLE_TERM_OPEN varOrTerm verb objectList TRIPLE_TERM_CLOSE ; |
There was a problem hiding this comment.
[Question] Does this incorporate the case with <<( ... )>> ? (e.g., when using BIND or querying with the rdf:reifies predicate)
There was a problem hiding this comment.
Resolved in the latest commit
| @param query the original query string. | ||
| @return the preprocessed query string with triple terms replaced by placeholders. | ||
| */ | ||
| std::string QueryParser::preprocessTripleTerms(const std::string &query) |
There was a problem hiding this comment.
[Question] Recalling the question in SPARQL.g4, is it possible to catch both cases (with and without parentheses) in the grammar so no manual parsing here is needed?
There was a problem hiding this comment.
The problem is semantic, identical <<(...)>> needs different treatment depending on context:
- decomposition when it's a subject
- literal value when it's the object of rdf:reifies.
ANTLR grammar has no way to know which context it's in. That is why the preprocessor + addTriple split exists.
2 participants
No description provided.