Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  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.


  1. Set up the technical infrastructure for HSACL generation based on the a couple of basic examplesPawel 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


  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
    , 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.