Re: [shex] Inheritance of Shape Expressions

## Vitals diamond
I've created a demo which could benefit from inheritance. Logically, it has a diamond inheritance pattern (B and C inherit A and D inherits from B and C). Select `vitals diamond` in this [conventional example](http://rawgit.com/shexSpec/shex.js/master/doc/shex-simple.html?manifest=../examples/inheritance/manifest.json).
```
                     <Observation>                
                     ／／       ＼＼
        <Vital>:   <BP>         <Pulse>                 
                    |                 |
                    |    <Posture>    |
                    |     ／ |  ＼    |
<PostureVital>:  <PostureBP> | <PosturePulse>     
                    |        |        |
                    |     <Reclined>  |
                    |     ／   ＼     |
<ReclinedVital>: <ReclinedBP   <ReclinedPulse>    
```
This example assumes that the person who extended `<BP>` and `<Pulse>` either had the power to add some triple expression labels to them (`<BP-TE>` and `<Pulse-TE>`) or some kind soul had already labeled every possibly-useful combination of triple expressions.

The `<Vital>`, `<PostureVital>` and `<ReclinedVital>` are just disjunctions of convenience for some e.g. data structure which references a `<Vital>` or some such structure.

## Vitals path
The manifest includes a couple syntaxes for getting around these assumptions (with terser text):
`vitals path`: adds the ability to address a triple expression by following a JSON path from a shape expression label. It has examples which include all of the intervening JSON path:
* `&<#BP>.shapeExprs[1].expression`
* `&<#Posture>.expression`

and some that assume by defaults that [n] applies to nth shapeExpr and that addressing a Shape in a triple expression inclusion means you want the `expression`:
* `&<#BP>[1]`
* `&<#Reclined>[1]`

This strategy would require augmenting the syntax for references (currently just an RDF node per JSON-LD reference rules) and on its one doesn't do anything to address the need for the disjunctions for `<Vital>`, `<PostureVital>` and `<ReclinedVital>`. I added some `EXPANDS` keywords to the example to show how that could be handled by an orthogonal extension to ShEx.

## Vitals operator
Another strategy, the one I've been entertaining for a while, is to have inheritance implied both by extension and restriction operators (`&` and `-` respectively). This appears to align with the inheritance rules from the programming language `Eiffel` (known for taking inheritance seriously) but I'm not an Eiffel expert. I believe there's a way to effectively compile this into the structure of `vitals diamond` but we'll see what I can prove in code in the next couple days.

My preference is to use operators and to add some structural rules ([we already have a few](https://shexspec.github.io/spec/#schema-requirements)] to constrain it to a few practical cases like when the shape expression label references a simple shape or a conjunction with only one shape in it. I think this gives us time to get something out without painting ourselves into a corner while we wait for more complex use cases to float our way.

-- 
GitHub Notification of comment by ericprud
Please view or discuss this issue at https://github.com/shexSpec/shex/issues/50#issuecomment-354565224 using your GitHub account

Received on Saturday, 30 December 2017 19:57:49 UTC