SHACL constraint definitions of DocMaps

[ships]

Currently, "a docmap" is defined conventionally as a subspecification of a pwo:Workflow, but without much tooling around them yet, we have an opportunity to avoid overspecifying how the community will implement and use them. Because docmaps may be nested, and generally do support a graph-like structure (not just a tree-like structure), it will be advantageous down the road if our ecosystem can take advantage of the RDF / LD toolchains such as @rdfjs and eventually SPARQL.

However, OWL inference logic is notoriously counterproductive in a mixed-trust open world. The statement

:Docmap a owl:Class, rdfs:Class ;
    owl:subclassOf pwo:Workflow

gives us the leeway to define quite expressive constraints in SHACL that can bind the docmap type. Side effect may be easy generation of TS types that can be piped into from RDF streams for uses like d3.js in browser, or destructuring in a Node context.

I am exploring this approach this week.

[ships]

#10 added the first round of these constraints. The next step is to integrate the SHACL into any single piece of useful tooling and see how it spins.