Closed afs closed 3 years ago
I am not sure it is possible to reuse the EmbTP
rule here without restrictions: EmbTP
allows blank nodes that are not allowed in SPARQL expressions. What about introducing a new rule:
EmbTPExpr ::= '<<' PrimaryExpression PrimaryExpression PrimaryExpression '>>'
and consider it an alternative writing of the TRIPLE
function?
Thanks for pointing that out.
PR set to "draft".
The idea is that it should be like a term in a graph pattern, so it is not full PrimaryExpression
which allows ( expression )
and functions and built-ins.
I think it is going to have to be written out as a specific form of vars or constants, and also a
for the predicate slot. (And so avoids going near related matching forms SPARQL 1.1 does not have ?str@en
and ?lex^^:datatype
.)
For evaluation definition, TRIPLE
can be used as it covers all the cases (and more).
Pushed an update for the grammar.
ExprVarOrTerm
can be written using 177/DataValueTerm but that is currently specifically for VALUES or using iriOrVar
but as rule names have implications so it seemed clearer to enumerate the cases.
It will need some stylistic reorganisation to fit with the grammar section. Rules119a and 119b are placed close to use for clarity for now but style is to group new productions at the end.
This PR now has:
PrimaryExpression
involving <<>>
.<<>>
in an expression context (added new section 4.4.6). It is defined as being the same as TRIPLE
with the expressions allowed by the syntax for <<>>
.@pchampin This now adds a section 4.4.6 for evaluation of << >>
in expressions.
Addresses issue #163.
Preview | Diff