shexSpec / shex

ShEx language issues, including new features for e.g. ShEx2.1
23 stars 8 forks source link

Consider adding property paths to ShEx #6

Open labra opened 8 years ago

labra commented 8 years ago

In some cases, it may be interesting to be able to define something like:

<GrandParent> { :child/:child IRI } 

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

<grandParent> { :child { :child IRI } }
ericprud commented 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:

Translations

ShEx nested shape SPARQL property path
:child { :child .* }* :child/:child
:child { :child . } nested SELECT
- outside expressivity - :child*/:child
ericprud commented 5 years ago

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.

andrawaag commented 4 years ago

Move it to a feature request/discussion in the context of a 2.2 or x release