SHACL/SKOS Question

[Tim Smith]

Hi,

I have a taxonomy called "Security Classification" that contains five classification levels in a hierarchy modeled using skos:broader.  This was manually created in an EDG Taxonomy as the "Security Classification Concept Scheme".

I have added a property/property shape to edg:InformationAsset using a new property :securityClassification.  I'm struggling with how to assert that all values of the property :securityClassification must be a member of the Security Classification Concept Scheme.  The simple thing to do would be to also create a Security Classification class and make all concepts instances of the class, leaving SKOS as the vocabulary by which I structure the terms.  Then sh:class can be used to define the values.  This appears to be how the Geography Taxonomy and Geo Ontology work together.  Doing so also feels redundant as I can see needing to make an ontology that mirrors my Concept Schemes for all cases where I need to restrict values to a specific Concept Scheme.

Is there a recommended design pattern for using concept schemes as the values for a property shape?  I'm looking for a solution that EDG will support, i.e. limit the values the user can select on a form to the specific Concept Scheme members.

Thanks in advance for your assistance,

Tim

[Irene Polikoff]

Hi Tim,

See below

On Aug 23, 2021, at 2:05 PM, Tim Smith <smith...@gmail.com> wrote:

Hi,

I have a taxonomy called "Security Classification" that contains five classification levels in a hierarchy modeled using skos:broader.  This was manually created in an EDG Taxonomy as the "Security Classification Concept Scheme".

I have added a property/property shape to edg:InformationAsset using a new property :securityClassification.  I'm struggling with how to assert that all values of the property :securityClassification must be a member of the Security Classification Concept Scheme.  The simple thing to do would be to also create a Security Classification class and make all concepts instances of the class, leaving SKOS as the vocabulary by which I structure the terms.  Then sh:class can be used to define the values. 

Correct, defining a class :SecurityClassification is the way to go

This appears to be how the Geography Taxonomy and Geo Ontology work together.  Doing so also feels redundant as I can see needing to make an ontology that mirrors my Concept Schemes for all cases where I need to restrict values to a specific Concept Scheme.

Well, the notion of a skos:ConceptScheme as well as the notion of skos:Collection where can have members is essentially poor man’s classes. In other words, it lets users define sets of resources without using classes. The downside, as you have discovered, is that there is no simple way to say that values of a property (e.g., :securityClassification property) must be members of a concept scheme or members of a collection.

Is there a recommended design pattern for using concept schemes as the values for a property shape?  I'm looking for a solution that EDG will support, i.e. limit the values the user can select on a form to the specific Concept Scheme members.

No. This would involve specifying a complex path that includes :securityClassification and skos:inScheme. It would work for validation (provided that inScheme value is populated - by default, it is not), but not for selection of values on a form. 

Thanks in advance for your assistance,

My recommendation would be to use Enumerations asset collection and create edg:EnumeratedValue for this. This is how statuses, confidentiality classifications, etc. are already handled in EDG:

You can extend it with the skos:broader or any other hierarchical property. It is not clear to me that skos:ConceptScheme adds value. I am not even sure you need a hierarchical property in this case. It seems more like an ordinal value e.g., Top Secret is higher than Secret.

I also don’t believe that edg:InformationAsset is intended for something like this. It was designed to support capturing information about reports, forms, etc.

Tim

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2B0qg_u4qbJsC2bmRLbG2sFUgCeHKMJ32x2v7M3hpEkfw%40mail.gmail.com.

[Tim Smith]

Thanks Irene!

I have created an enumeration for Security Classification and it works nicely.  In this case, I have a list of 3200+ types of "Content", many of which are reports, permits, agreements, etc... so Information Asset will work for some percentage of the 3200.  As I have time, I will refine the class assignments for each item in the list.  For now, I'm trying to convince my colleagues that expressing this information in EDG provides a much better platform than the existing home (MEGA) so speed is more important than 100% semantic accuracy.

Thanks again for your help,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/41C619DA-A2DC-4A0A-9053-58A8BBE0B90D%40topquadrant.com.

[Holger Knublauch]

For the record, there is a solution for this built into EDG. Assuming you have the SKOS shapes namespace imported into your ontology, you can switch to SKOS-specific constraints (or activate Merged mode) to see the property "from concept scheme"

The values of that are skos:ConceptScheme instances, and the constraint is that all values of the property must be part of that scheme. Then select the corresponding editor for the same property:

which is an auto-complete editor that only shows suitable values from the provided concept scheme.

For the technical record, here is the definition of the underlying constraint component:

skosshapes:FromConceptSchemeConstraintComponent
  a sh:ConstraintComponent ;
  dash:propertySuggestionGenerator tosh:DeleteTripleSuggestionGenerator ;
  rdfs:comment "A SHACL constraint component that can be used to state that all value nodes must be concepts from a given skos:ConceptScheme." ;
  rdfs:label "From concept scheme constraint component" ;
  sh:labelTemplate "Values need to be concepts from {?fromConceptScheme}" ;
  sh:parameter skosshapes:FromConceptSchemeConstraintComponent-fromConceptScheme ;
  sh:validator [
      a sh:SPARQLAskValidator ;
      sh:ask """ASK {
    $value skos:broader* ?concept .
    $fromConceptScheme skos:hasTopConcept ?concept .
}""" ;
      sh:message "Value must be from concept scheme {?fromConceptScheme}." ;
      sh:prefixes <http://topbraid.org/skos.shapes> ;
    ] ;
.

Note that any shape declarations must be stored in Ontology asset collections, i.e. the Ontology needs to owl:import the ConceptScheme's definition (at least it needs to have the instances of skos:ConceptScheme - it doesn't require all the Concepts under them).

HTH
Holger