Connecting two separate property shapes in a Form when sh:path + sh:class pairings aren't enough

[Steven Folsom]

We have a situation where we're using a the same sh:path (bf:soundCharacteristic) with the same sh:class (skos:Concept) in multiple property shapes in the same Form Node Shape, and we want to use another sh:path (bf:soundCharacteristic/skos:inScheme) and sh:hasValue (the various skos Schemes) to further constrict which Concepts from which Schemes each property shape uses. 

The best I can come up with is the following, but it only says in this form for when using any property shape using bf:soundCharacteristic should have a skos:Concept from one of these schemes. Not that a specific property shape should use a specific subset of skos:Concepts from a particular scheme.

bibliotek-o_shapes_audio:AudioInstanceForm

   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A number of sound channels used to make a recording." ;
      sh:name "Configuration of playback channels" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A groove width of an analog disc." ;
      sh:name "Groove width of an analog disc" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A groove width of an analog disc." ;
      sh:name "Groove width of an analog disc" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A groove pitch of an analog cylinder." ;
      sh:name "Groove pitch of an analog cylinder" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "An equalization system, noise reduction system, etc., used in making an audio recording." ;
      sh:name "Special playback characteristic" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A relationship between an original carrier and the carrier of a reproduction made from the original." ;
      sh:name "Kind of disc, cylinder or tape" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
    sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> ;
      sh:description "A method used to encode audio content for playback.." ;
      sh:name "Type of recording" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:class <http://www.w3.org/2004/02/skos/core#Concept> ;
    ] ;
   
  sh:property [
      sh:path <http://id.loc.gov/ontologies/bibframe/soundCharacteristic/skos:inScheme> ;
      sh:description "Terms for sound characteristics should be taken from RDA Values List or individuals from Performed Music Ontology" ;
      sh:name "Sound Characteristics" ;
      sh:group bibliotek-o_shapes_audio:AudioInstanceCharacteristicsPropertyGroup ;
      sh:nodeKind sh:IRI ;
      sh:or (
          [
            sh:hasValue <http://rdaregistry.info/termList/configPlayback>
          ]
          [
            sh:hasValue <http://rdaregistry.info/termList/groovePitch>
          ]
          [
            sh:hasValue <http://rdaregistry.info/termList/grooveWidth> ;
          ]
          [
            sh:hasValue <http://rdaregistry.info/termList/specPlayback> ;
          ]
          [
            sh:hasValue <http://rdaregistry.info/termList/RDAGeneration> ;
          ]
           [
            sh:hasValue <http://rdaregistry.info/termList/typeRec> ;
          ]
        ) ;
    ] ;

Thanks in advance for any advice,

Steven

[Irene Polikoff]

Steven,

The answer depends on what are your goals in creating these shapes.

If your goal is data validation to check that only certain concepts (those in the concept schemes you’ve listed) are used as values of  <http://id.loc.gov/ontologies/bibframe/soundCharacteristic>, then the very last shape you have already does the job. You will get a violation if a concept used is not in one of these schemes. You could also use sh:in in this shape, instead of a combination of sh:hasValue with sh:or.

I would recommend not using sh:nodeKind in this shape. It does no harm, but I suspect that, as a general rule, you want only IRIs to be used as subjects of triples with skos:inScheme predicate. If so, I recommend having a separate shape to check for this condition - use {sh:targetSubjectsOf skos:inScheme} to define your targets and check that they are IRIs. You can also check that they are of rdf;type skos:Concept. These type of conditions are likely to apply universally and not limited to values of <http://id.loc.gov/ontologies/bibframe/soundCharacteristic>. Which is why I am suggesting a separate shape.

If your goal is to have a UI where users get different drop downs for this property, depending on the context, then your model is not rich enough to support such behavior.  You need to:

• Create a different property for each of these different characteristics of sound. (if you could use qualified value shapes, then may be you could avoid having different properties)
• Create different subclasses of skos:Concept e.g., Groove width, Groove pitch, etc. 
• Then, Instead of using a path with <http://id.loc.gov/ontologies/bibframe/soundCharacteristic>/skos:inScheme, use these new properties with sh:class constraint to the corresponding classes

UI drop downs are based only on certain types of constraints e.g., sh:class, sh:in, sh:datatype. One could create arbitrary complex combinations of constraints in a shape and they will be checked against when validating data, but it is unrealistic to assume that the UI will be calculating them in real time in order to generate a calculated drop down list. If one doesn’t limit what is supported such operations could get prohibitively expensive and a common UI requirement is 2-3 seconds response time. 

Even if we put the performance issue aside, your current model is still not rich enough. There is no way to understand, for example, that where you say sh:name "Groove width of an analog disc”, you would only want for values of <http://id.loc.gov/ontologies/bibframe/soundCharacteristic> a dropdown with some specific concepts. In cases, where it is possible to define cardinalities, qualified value shapes could be used to say this https://www.w3.org/TR/shacl/#QualifiedValueShapeConstraintComponent, but given your situation where the values for the property you want a drop down for are not constrained directly, but through some other nested/referred statements, this by itself is not enough for the UI, you would still need to enrich the model a bit.

In general, skos:inScheme is a “poor man” option for the idea of classes (as subclasses of skos:Concept) and class membership and for the idea of grouping a set of resources in a graph - something that can be done as a named graph. In either case, it doesn’t do as good of a job as these other alternatives. Thus, I don’t see much value in using it. If you want to, you could use it in addition to these other, more expressive and explicit methods, but I don’t think it adds much, if any, value.  In short, if you want a model-driven UI, you need to create a model that will make it possible.

Regards,

Irene Polikoff

-- 
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.
For more options, visit https://groups.google.com/d/optout.