Use Cases for SHACL

1. Constraints validation (required by BI, Amgen) 
2. Template for the graphical user interface (GUI (; required by Bayer)

For those two use cases, in some cases, there is a slight difference in the SHACL constraints in some cases. Namely Specifically, for the GUI usageuse case,

1. there are certain transformation shortcuts required, e.g., to drop name instances
2. some attributes need to be either sorted or filtered out, e.g., preferred names.

For now, we just focus on use case 1.

Next steps:

1. Set up the technical infrastructure for HSACL generation based on the a couple of basic examples. Pawel Garbacz  the  the first 3 rows from the table that are clear

Open topics to clarify before the generation can start

1. Review/finalize the table
   1. Mapping of owl:hasValue → RESOLVED, as in the table
   2. mapping of OWL domain and range to SHACL - RESOLVED, as in the table
2. Open vs closed world assumptions
3. Portion of Water - Thomas checks with Elisa
4. Untyped nodes - resources that do not have rdf:type

Automation Design

...

1. All SHACL shapes are based on OWL restrictions that are superclasses of (named) classes - see the list of those in - scope below.
2. All SHACL shapes are defined only for on leaf-classes, i.e., classes without subclasses.
3. Inherited constraints, i.e., constraints that can be inferred from superclasses, are dropped.

4. We assume sh:closed=False.

5. In the context of

   Jira Legacy
   server jira.edmcouncil.org columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6465cde0-d6c9-34a0-a506-4d4ac3461fe5 key IDMP-526

   , the agreement was reached that we should categorize constructs that can be generated straightforwardly and the complex ones that require manual intervention. The two categories should then be maintained separately in the Git repository and used combined.

...

Some cases are not displayed here, e.g., for the owl:allValuesFrom when B is rdfs:Literal.

Open vs closed world assumptions

OWL differs from SHACL also with respect to the assumption regarding the implication of a statement being absent:

...

Pawel Garbacz believes that translation from OWL to SHACL needs to adopt the target assumption, i.e. the closed-world assumption. This assumption will affect only the OWL existential statements - in order to mitigate its impact we may assume that violations of such constraints will be sh:Warning.

Constraints inheritance

If an ontology contains the following OWL axioms:

...

Then axiom 2 will not be shaclised because it is inferable from axiom 1.

Constraints Relaxation

If an ontology contains the following OWL axioms:

...

SomeRBPropertyShape a sh:PropertyShape;
sh:path R; sh:class B; sh:minCount 1.

SomeinverseOfRBPropertyShape a sh:PropertyShape;
sh:path [inverseOf R]; sh:class B; sh:minCount 1.

ANodeShape a sh:NodeShape;
sh:property sh:or (SomeRBPropertyShape SomeinverseOfRBPropertyShape).

Exemplary outputs

SHACL Shapes #1

Scope:

1. ISO11238-Substances
2. A rdfs:subClassOf some R B

...