Open labra opened 8 years ago
[reopened - apologies for the click-o]
I believe that property paths are a generalization of nested properties, e.g.:
<PatientShape> {
<name> {
<given> LITERAL;
<family> LITERAL
}+
}
could be represented (with some loss of cardinality specificity) as
<PatientShape> {
<name>/<given> LITERAL+;
<name>/<family> LITERAL+
}
This uses the property path to traverse to a value which is then constrained by a NodeConstraint.
Two challenges arise:
cardinality; If we use a traditional SPARQL property paths interpretation, <name>/<given> LITERAL+
could mean that there are 1+ <name>
s, each with a single <given>
property, a single <name>
with 1+ <given>
properties, or 1+ <name>
s, each with 1+ <given>
s. If we allow SPARQL property path cardinalities, we need to figure out what <name>+/<given>+ LITERAL+
means.
CLOSEDness: what's it mean if there's a to close e.g. <PatientShape> CLOSED { <name>/<given> LITERAL+ }
; do we reject e.g. `<patient1> <name> [ <given> "Alice"; <somethingElse> true ] .
Translations
ShEx nested shape | SPARQL property path |
---|---|
:child { :child .* }* | :child/:child |
:child { :child . } | nested SELECT |
- outside expressivity - | :child*/:child |
Note that for many use cases involving a property path and a cardinality, the SHACL behavior is pathological; it UNIQUEs the pair of starting node and reached node. For example, a use case like making sure that only one check was written for a particular invoice (sh:path (:paymentCheck :amount); sh:maxCount 1
) will not detect multiple checks written for the same amount.
Move it to a feature request/discussion in the context of a 2.2 or x release
In some cases, it may be interesting to be able to define something like:
which instead of using a single predicate in the triple constraint, uses a property path similar to SPARQL property paths.
At this moment, the previous example can be defined as