Re: SHACL Shape definition for including and excluding parent types

Thanks for the response, Vadimir.  Unfortunately, changing to another
engine is a non-starter.  SHACL is just one element of a set of systems for
developing and using ontologies and taxonomies that have many dependent
downstream (and upstream) components.  SHACL is a small part and would not
warrant adding or replacing any of the existing infrastructure.

-- Scott

On Wed, Sep 15, 2021 at 4:24 AM Vladimir Alexiev <
vladimir.alexiev@ontotext.com> wrote:

> Sorry I sent an incomplete email! Here's an edited version:
>
> >  the three main requirements (above 1), 2), 3) ) are prerequisites for
> applying other shapes.
>
> Hi Scott!
>
> You need to target by shape.
> You can't do this with standard SHACL.
>
> We at Ontotext added such extension to rdf4j ShaclSail because we needed
> it for the Ontotext Platform:
> https://rdf4j.org/shacl/extensions.html
>
> It didn't make it to SHACL Advanced because TQ thought it's not feasible
> to implement.
> But it is, if you have incremental validation.
>
> In fact it's an important feature for scenarios when you have related
> shapes (very often),
> in order to avoid uncontrollable expansion of validation work.
>
> Recursive shapes are not allowed in SHACL (the result is undefined), eg
> - "shape Company is a foaf:Organization  that may have Employees"
> - "shape Employee is a foaf:Person that has employer, being a Company"
>
> But even in non-recursive cases, we found it very useful to have two shape
> flavors for each "business object":
> - a Lite shape that discriminates between business objects, and is used to
> check that references are valid (the target node exists and has the
> expected Lite shape)
> - a Full shape that checks all properties of the object
>
> This is what we use in the Onotext Platform for "type discrimination",
> see
> http://platform.ontotext.com/soml/objects.html#object-typing
>
> A simple example: thesaurus values usually use skos:Concept, and are
> further discriminated by skos:inScheme. Eg
>
> - (lite) "shape Industry is a skos:Concept with skos:inScheme being
> <industry>"
>   - and further (full) "it has :level being xsd:integer, and skos:notation
> matching a NACE regex, and may have skos:broader being Industry (lite)"
> - (lite) "shape Technology is a skos:Concept with skos:inScheme being
> <technology>"
>   - and further (full) "it may have skos:broader being Technology (lite)"
> - (full) "shape Company is foaf:Organization that has one primaryIndustry,
> may have more industries, and may have several technologies"
>
> We use this distribution of work:
> - When checking (full) "shape Company" we use the (lite) shapes of
> Industry and Technology, to ensure Company refers to existing and
> appropriate nodes.
> - We check the (full) shapes "Industry" and "Technology" only when new
> "business objects" of that kind are in the incoming transaction.
>   How do we pick what objects are incoming? By using the (lite) shapes,
> and targeting by these shapes
>
> Sorry, I'm in a hurry now so maybe the above is not very clear. Will write
> a blog post about it.
>
> Scott, if this sounds like it can be useful to you, please contact us
> directly.
> Cheers!
>