Explore relationship between templates and RDF Shapes/ShEx

There are similarities and differences in semantics and use cases between templates (dosdps, robot, ottr) and shapes (shex, shacl).

We should explore these and formalize the linkages, and possibly even explore if there is a possible subsuming framework.

Some background: This is being driven in part by the [go-shapes](https://github.com/geneontology/go-shapes/blob/master/shapes/go-cam-shapes.shex) schema which is used to validate GO-CAMs but is increasingly becoming a general source of all truth about GO. Originally we had shapes only for obo-core level classes such as BiologicalProcess, CellComponent. But we are seeing the need for deeper subclasses; eg a transport subclass that we can parameterize with start-location and end-location.

This is obviously partly **duplicative** with the [dosdp templates for go](https://github.com/geneontology/go-ontology/tree/master/src/design_patterns). This is not super-satisfying. Aside from duplication of effort, the worst effect is duplication of mindshare and confusion over not having one source of truth.

A current very rough proposal:

- have a convention for annotating shex with information needed to make it on-par with dosdps. Call this t-shex
- shex is v nice for annotating any part of a shape with annotations
- we can imagine annotating the range constraint with a variable name and the shape with a generator string
- write a t-shex to dosdp (or robot template header) converter
- note the shex would be abox-based, but it would be trivial to generalize to a defining tbox expression
- OR adapt dosdp-tools to go from t-shex. This gets around a whole bunch of issues such as optional variables
- gradually migrate patterns to t-shex

E.g.

```
AND EXTRA a {
has-start-location: // dosdp:var "start"
has-end-location: // dosdp:var "end"
} // rdfs:comment "this is for transport"
dosdp:labelGen "transport [from {{start}}] [to {{end}}]"
` dosdp:textdefGen "..."
```

no need for an equiv axiom generator: all the information is in the abox pattern

You could feed this either tuples (with optional fillers) or actual subgraphs, in order to do class generation

I am also assuming in the future many tools for doing things like driving form interfaces from shex/shacl (which are partly interconvertible)

I think there are many advantages to doing this for GO. We are becoming more abox-based. A lot of the standard tooling in ShEx is really nice, and it's a widely adopted standard.

This could just be creating busy work for other uses of dosdps, e.g. they have been phenomenally successful for phenotype reconciliation.

The counterpoint to all of this is skepticism about finding the One True Framework to bind them all ([biolinkml](https://github.com/biolink/biolinkml)?)

## See Also

* discussion on semantic-web mail list about relationship between shapes and generative frameworks: https://lists.w3.org/Archives/Public/semantic-web/2019Nov/0004.html

## cc

@vanaukenk @dosumis @matentzn @balhoff @goodb @ukemi @jamesaoverton @beckyjackson

Start by comparing the go-shapes schema in go-cam-shapes.shex with the dosdp templates under src/design_patterns, then review the referenced dosdp-tools approach. The issue is complete only when the relationship between shapes and templates is formalized well enough to support an agreed framework or conversion path.

Written by the indexing model from the issue text.