AP model stereotypes need refinement and mapping to shacl

[sixdiamants]

The Application Profile defines mandatory, recommended, and optional elements.

It makes sense to discuss the meaning of the stereotypes in terms of SHACL messages that non-conformance would generate. This allows one to hammer out the intention.

• What does it mean when a mandatory attribute has multiplicity [0..n]. Mandatory, optional, arity 0..* aren’t orthogonal. o There should a “nillable” requirement to deal with absent attributes. For instance the statement “this wheel vehicle has null wheels” means “this wheel vehicle has an unknown number of wheels”. This is like "entry left blank on purpose". o Situations arise where insight grows and facts are added by-and-by. Some datasets use nulls to indicate “I’m aware that this attribute must be informed but at this stage its value is unknown”. The SHACL message should reflect this by issuing a warning like “The attribute is blank. Confirm that this is intended”. Upon maturity, these messages should all be gone. Thus, a wheel vehicle has a <mandatory,nillable> attribute “numberOfWheels” and an individual “MyMotor” would have numberOfWheels=null which at a later stage would turn to numberOfWheels=3. o A model attribute <optional,nillable> numberOfWheels [0..1] can express:

  1. numberOfWheels = null means “will be informed later”
  2. numberOfWheels absent means “irrelevant for this application”
  3. numberOfWheels = 2 asserts “2 wheels”
  4. numberOfWheels = 0 asserts “no wheels”

• How does one express nillability in RDF ?

• An application may need mutually exclusivity such as “for an individual person, provide either age or date of birth”. Defining Attributes age[0..1] and dateOfBirth[0..1] is too lax and stereotyping doesn’t help either. o sh:xone can express this in SHACL but UML can't. In a previous project, we simply attached a UML note saying "XOR".

Here's my suggestion for the set of requirement levels, note that I dropped "optional" because I'm unaware of the difference between arity [0..n] and optional :

[sixdiamants]

Modulating properties in an AP by means of the switch mandatory/optional/recommended will be reflected in SHACL shapes. Thus, I would expect that the SHACL shapes need to be (de-)activated.

In accordance with the good practice recommended by the SHACL spec the style guide may want to recommend that

1. property shapes are named nodes as opposed to blank nodes (which is already the case in model2owl)
2. the sh:deactivated triple is used to hint that a shape can be toggled in an AP.

[sixdiamants]

Subsidiary question about the meaning of the class-application-profile and the requirement level when applied to classes:

One needs to define whether an AP is designed to

1. only accept instances of stereotyped classes in the DCAT-AP profile or
2. accept instances of all classes where stereotyped classes in the DCAT-AP are considered "tailored" to the AP.

Answer 1 implies that one needs to carefully include each and every class needed to capture the AP requirement (very closed world). Also, can one generate SHACL to exclude inacceptable individuals ? Answer 2 may be too open to abuse because nothing stops a user from instantiating the "original" classes that aren't within the profile.