Node Expressions : base definition and evaluation #322
Comments
|
We should also revisit the name "function". I think it would be better to reserve function to how the term is used in SPARQL, for a single function IRI with an ordered list of parameters. I think for the more general concept, the term "type" isn't that bad after all, because some node expressions COULD use it as rdf:type. |
|
That would be better as "SPARQL function". The word "function" is the mathematical concept of mapping from domain to range, and which implies the arguments are evaluated before the function call is made to get elements in the domain. There are also "functional forms" - naming here is more varied; SPARQL uses "functional form". Functions are completely defined by their arguments. Some things look like "functions" but aren't e.g. |
|
Ok taking this further, what about these kinds of node expressions
Maybe there is a better term than non-functional, but then, why not. Each node expression has a type, which for functions is the function IRI, for non-functions is the optional rdf:type. |
FWIW, I do like the term function. It may not match it's mathematical definition exactly but in a programming sense they all have some inputs and produce nodes as output, correct? Pretty functional to me. Yes, in triples an IRI or literal are valid expressions but that is only their representation. Their implementation is just as functional, being |
|
Constants can be considered as functions of zero arguments. |
|
It's probably better to have a special name for the function/one-return case. It's not necessary - make "tuple of list of RDF terms" the domain of functions; if one value is expected, it must be a list of one input - but that doesn't say how list-returns interact with use as NE expression arguments. Is that a cross-product? Pairing? Not allowed unless the function declares it takes 2 lists?
Functional forms look (syntax) like functions. They evaluate differently. |
|
(Putting this comment in so all Node Expression issues get mentioned on this discussion) #311 (comment) |
|
Some of us (Tom, Andy and I) will meet tomorrow at 12:00 Paris time to discuss various topics related to Node Expressions. Anyone from the WG is invited to join if interested. We will in any case report on the outcome, hopefully through some PR that the WG can review. SHACL Node Expressions General discussion on SHACL Node Expressions including
https://github.com/w3c/data-shapes/issues/322 |
|
Some (raw) Notes from the Node Expressions meeting on March 20. Present: @afs @simonstey @tpluscode David Habgood, @HolgerKnublauch We agreed to keep the division of blank node syntaxes for Node Expressions. Names of these two kinds may change:
Positional Argument Expression. sh:PositionalArgumentExpression We brainstormed about how shapes graph could define new node expression functions: For named parameter expressions more work is needed: An interesting suggestion was that we could put all these declarations into the Node Expression document itself, without delaying SHACL Core or SPARQL. All we really need to say in Core is that Constant expressions exist and that the handling of blank nodes will be defined by the Node Expr document. |
|
On further iteration on the names, what about
and then use sh:parameter and sh:listParameter to declare them? This avoids the term "argument", and "list" describes what is going on in the syntax quite well? Also, I have some concerns about introducing the intermediate predicate such as ex:MultiplyList in the example at the bottom of the post above. The problem here is that this syntax would look different from the built-in named parameter expressions. Over time, it is quite possible that many people will publish new libraries of node expressions, e.g. based on SPARQL design patterns for specific ontologies such as SKOS. It should be possible to use those consistently with the built-ins. So I suggest that the user-defined expression types also declare a key parameter. |
Looks good - or "...ParamExpr" if the user has to write the things quite frequently. |
Could you show an example or two? |
Thinking about it now, I don't expect users will have to write that at all. In fact, it would be best if they were completely optional. like They are already unambiguous by using the I stand by defining parameters according to the type of expression (arguments being the actual values, as appears to be widely accepted). Positional: ex:multiply
a sh:PositionalArgumentExpression ; # optional
- sh:argument [ # Probably needs a different term
+ sh:parameters ( [ # Might use plural
sh:varName “op1” ; # Use varName instead of sh:path
sh:datatype xsd:decimal ;
- sh:order 0 ;
- ] ;
- sh:argument [
+ ]
+ [
sh:varName “op1” ;
sh:datatype xsd:decimal ;
- sh:order 1 ;
- ] ;
+ ] );
sh:expression [
sh:eval “$op1 * $op2” ;
] ;
sh:returnType xsd:decimal .
ex:Shape sh:targetNode [ ex:multiply ( 40 2 ) ] |
|
The new PR leaves the remaining details to the Node Expr document, including the syntax for user-defined node expression types. The only thing we may need to adjust is the exprEval function, but let's keep Core lean so that this isn't blocking progress and we remain flexible. |
@simonstey , @robert-david , @recalcitrantsupplant -- what do you think of this? |
|
I think that's a good thing as we wouldn't have to rush a half-baked spec. for NExpr out fast for phase 1, but can flesh it out in phase 2. |
|
I think it's sensible. I like the direction of the changes so far but would like more time to play with examples. |
The current (2025-03-12) definition of Node Expression in SHACL Core reads as:
as if the only way to invoke a function is by its function name which isn't true (IRI expression, literal expression).
Alternative:
A node expression is one of
and the definitions of "IRI expression" and "literal expression" need changing (they can be used as direct terms or via their function name).
Evaluation is defined as
eval(expr, activeGraph, scope)How to paramaters and positional arguments e.g.
[ fn:strlen ( someWayToGetInputFocusNode 2 3 ) ]get passed to the evaluation step?
scope?The text was updated successfully, but these errors were encountered: