Node Expressions

[afs]

This issue is for general discussion of Node Expressions.

Node Expressions in SHACL-AF (May 2017).

SHACL CG draft with a longer list of possible node expressions

Wiki doc: Proposal on Node Expressions for SHACL Core 1.2

Use cases:

• Issues labelled "Inferencing and UCR"

Please add use cases, small or large, as issues and label them "Inferencing" and also "UCR". We can do further organisation later if the volume is high enough.

The full work on this area is phase2.

However, some of the ideas also apply to to SHACL core in phase1. We need to know what is the vision of "node expressions" so that phase1 documents are aligned.

[tpluscode]

I have been using Node Expressions extensively for generating SPARQL queries from shapes: https://shape-to-query.hypermedia.app/docs/

[afs]

@HolgerKnublauch

On the description page, I don't understand the second edg:Database-tableCount example. It uses sh:path on the property shape but it does not evaluate to a path. What would the new SHACL-core definition of sh:path look like?

edg:Database-tableCount
    a sh:PropertyShape ;
    sh:inferredProperty edg:tableCount ;
    sh:path [                       ## ????
        sh:count [
            sh:path [
                sh:inversePath edg:tableOf ;
            ] ;
        ] ;
    ] .
    sh:datatype xsd:integer ;
    sh:description "The number of tables in this database, automatically computed." ;

From the description of it, this seems to be a prototype/template for a first example edg:Database-tableCount - a "property shape" but it does not have a sh:path (= reachability for value nodes), it has sh:inferredProperty instead and values of the object. sh:inferredProperty.

edg:Database-tableCount
    a sh:DerivedPropertyShape ;
    sh:inferredProperty edg:tableCount ;
    sh:values [
        sh:count [
            sh:path [
                sh:inversePath edg:tableOf ;
            ] ;
        ] ;
    ] .
    sh:datatype xsd:integer ;
    sh:description "The number of tables in this database, automatically computed." ;

related to:

	sh:rule [
		a sh:TripleRule ;
		sh:subject sh:this ;
		sh:predicate edg:tableCount ;
		sh:object sh:values [
                    sh:count [
                        sh:path [
                            sh:inversePath edg:tableOf ;
               ] ;
           ] ;

[HolgerKnublauch]

The first definition of tableCount used a sh:values rule, with 1.1 syntax and the sh:path of that was the (potential) inferred property. The new design is more flexible and allows the use of node expressions directly at sh:path, with the inferred property optional in case anyone wants to reference them from other node expressions.

The values of sh:path at PropertyShapes in 1.2 would be more general than previously. While current SHACL only allows property path expressions, 1.2 would allow any node expression in the sh:path position. This should not be confused with the use of sh:path in the inner block (sh:inversePath), which is a node expression that must point to an "old" property path. It may be best to use a fresh property instead for this use case, instead of sh:path. Also, since property expressions such as sh:inversePath will also be node expressions, it could just be dropped in your example:

           sh:rule [
		a sh:TripleRule ;
		sh:subject sh:this ;
		sh:predicate edg:tableCount ;
		sh:object [
                    sh:count [
                        sh:inversePath edg:tableOf ;
                    ] ;
               ] ;
           ] ;

Not sure if this is any clearer, please ask again if it isn't.

[afs]

Also, since property expressions such as sh:inversePath will also be node expressions, it could just be dropped in your example:

It was copied from your example :-)

This should not be confused with the use of sh:path in the inner block (sh:inversePath), which is a node expression that must point to an "old" property path. It may be best to use a fresh property instead for this use case, instead of sh:path

It's early days, but, yes, I think a new name would be better. sh:path is central to SHACL and defines sh:PropertyShape.

Maybe extend the definition of property shape to be "must have exactly one of sh:path or one sh:inferredProperty".

[philharveyonline]

The general direction proposed in Proposal on Node Expressions for SHACL Core 1.2 looks really useful for our requirements.

I recorded a related use case that we've got in #227 .

[afs]

Picking up from #234 (comment)

• The use of functions as node expressions would become a node expression in SHACL-SPARQL if we elect to limit them to SPARQL functions, otherwise no clue. For example, we also support JS-based custom functions.

Being able to give a name to a node expression so it can be used in several places seems a likely need. That doesn't need the full function definition (it does not need to declare parameters, or return type necessarily).

my:nodeExpr_numTables
    rdf:type sh:nodeExpression ;
    sh:datatype xsd:integer ;     ## Optional
    sh:description "Calculate the number of tables in this database" ;
    sh:values [
        sh:count [
            sh:path [
                sh:inversePath edg:tableOf ;
            ] ;
        ] ;
    .

It will need a call syntax so that the node expression call site is a blank node (otherwise it is a constant term expression)

    [ sh:call my:nodeExpr_numTables ]

[hmottestad]

I also got confused with the use of expressions within sh:path. My first thought was also that the expression within a path was a way to dynamically calculate the path.

ex:person a foaf:Person;
   ex:agePath ex:useThisAsThePredicateToRetrieveTheAge;
   ex:useThisAsThePredicateToRetrieveTheAge 74.

So we could have a shape that checks that the age of a person is within a valid range, without knowing the specific predicate that the subject uses to define the age.

[afs]

Here is some exploration of node expressions.

Examples:

1. Calculate and test a substring
2. Is the focus node, as a date, within 30 days of today? (e.g. shop returns policy)
3. A rules related case: generating new IRIs - like having an identifier ":employeeId 123" and making IRI http://.../employee/123

"F&O" is "XPath and XQuery Functions and Operators"
Many SPARQL functions are defined using this large collection of functions.

PREFIX fn:      <http://www.w3.org/2005/xpath-functions#>
PREFIX op:      

op: is the operator prefix for F&O. It does not have URI but it can be the same as that for fn:.

Example 1

## Calculate and test a substring 
[ sh:equals ( [ fn:substr (sh:this 5 4) ] "ABCD" ) ]

Example 2

## Date within 30 days of today
## SPARQL with support for XSD Duration
##    ( now() - $this < "P30D"^^xsd:dayTimeDuration )

[ op:dayTimeDuration-less-than (
    [ op:subtract-dateTimes (
        [ sparql:now () ]
        [ fn:year-from-date sh:this ]
        )]
    "P30D"^^xsd:dayTimeDuration
  )]

Example 3

## Generate employee IRI

[ sparql:IRI
   [ fn:concat (
      "http://example/employee/"
      [ fn:replace ( sh:this "^[^/]*" "" ) ]   ## The last component of the IRI
   )]
]

Evaluation and function calling

This is my understanding of the node expressions proposal.

IRIs and literals are constants (sh:this is special)

Anything [ ] is a function call (sh:if is special)

[ ns:name () ]          ## No argument - must be RDF property-object
[ ns:name oneArg ]      ## Shorthand
[ ns:name ( args ) ]    ## General

sh:path accesses the graph starting from the focus node.

The SHACL-AF CG extended list of node expressions has set-based functions and aggregators. They take list arguments; the examples about take single values for each argument.

[simonstey]

This is my understanding of the node expressions proposal.

IRIs and literals are constants (sh:this is special)

Anything [ ] is a function call (sh:if is special)

[ ns:name () ]          ## No argument - must be RDF property-object
[ ns:name oneArg ]      ## Shorthand
[ ns:name ( args ) ]    ## General

sh:path accesses the graph starting from the focus node.

The SHACL-AF CG extended list of node expressions has set-based functions and aggregators. They take list arguments; the examples about take single values for each argument.

those NExp would still need to be used wherever we would allow NExp to be used right (i.e. within Shapes)? they can't just exist on their "own" (otherwise, what would sh:this point to?)

[simonstey]

Picking up from #234 (comment)

• The use of functions as node expressions would become a node expression in SHACL-SPARQL if we elect to limit them to SPARQL functions, otherwise no clue. For example, we also support JS-based custom functions.

Being able to give a name to a node expression so it can be used in several places seems a likely need. That doesn't need the full function definition (it does not need to declare parameters, or return type necessarily).

my:nodeExpr_numTables
    rdf:type sh:nodeExpression ;
    sh:datatype xsd:integer ;     ## Optional
    sh:description "Calculate the number of tables in this database" ;
    sh:values [
        sh:count [
            sh:path [
                sh:inversePath edg:tableOf ;
            ] ;
        ] ;
    .

It will need a call syntax so that the node expression call site is a blank node (otherwise it is a constant term expression)

    [ sh:call my:nodeExpr_numTables ]

why not adopt a similar approach like the already existing one for defining SPARQL-based Constraint components?:

sh:PatternConstraintComponent
	a sh:ConstraintComponent ;
	sh:parameter [
		sh:path sh:pattern ;
	] ;
	sh:parameter [
		sh:path sh:flags ;
		sh:optional true ;
	] ;
	sh:validator shimpl:hasPattern .

shimpl:hasPattern
	a sh:SPARQLAskValidator ;
	sh:message "Value does not match pattern {$pattern}" ;
	sh:ask """
		ASK { 
			FILTER (!isBlank($value) && 
				IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))
		}""" .