[SHACL] any shortcut for many sh:PropertyShape nodes differing only on sh:path?

[Emmanuel Oga]

Hi,

I have a bunch of properties which constraints that look like:

rf:topic-description a sh:PropertyShape ;

  sh:path rf:description ;

  sh:minCount 1 ; sh:maxCount 1 ; sh:nodeKind sh:Literal ;

  sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] [ sh:datatype rf:fishx ] ) ;

.

rf:topic-header a sh:PropertyShape ;

  sh:path rf:header ; 

  sh:maxCount 1 ; sh:nodeKind sh:Literal ;

  sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] [ sh:datatype rf:fishx ] ) ;

.

If you notice, the shapes differ only in sh:path. I was wondering if there's some mechanism I'm missing to specify that a property shape inherits from some other property shape, and adds some other specifics (for instance, that the sh:path is something in particular, but I think I could potentially have other properties like diff min and max counts, etc).

I was thinking of modeling this through SPARQL CONSTRUCT queries, but if the SHACL spec provides a solution already I'd prefer to use that!

Thank you,

E.

[Holger Knublauch]

One technique to avoid the multiple sh:or lists is to reuse them. For example, the dash namespace includes

dash:HTMLOrStringOrLangString
  rdf:type rdf:List ;
  rdf:first [
      sh:datatype rdf:HTML ;
    ] ;
  rdf:rest (
      [
        sh:datatype xsd:string ;
      ]
      [
        sh:datatype rdf:langString ;
      ]
    ) ;
  rdfs:comment "An rdf:List that can be used in property constraints as value for sh:or to indicate that all values of a property must be either rdf:HTML, xsd:string or rdf:langString (in that order of preference)." ;
  rdfs:label "HTML or string or langString" ;
.

which allows users to say sh:or dash:HTMLOrStringOrLangString.

You can also bundle similar constraints into a node shape and then use sh:node:

rf:SharedConstraints
  a sh:NodeShape

  sh:nodeKind sh:Literal ;

  sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] [ sh:datatype rf:fishx ] ) ;

.

rf:topic-description a sh:PropertyShape ;

  sh:path rf:description ;

  sh:minCount 1 ; sh:maxCount 1 ; .

  sh:node rf:SharedConstraints ;
.

rf:topic-header a sh:PropertyShape ;

  sh:path rf:header ; 

  sh:maxCount 1 ;

  sh:node rf:SharedConstraints ;
.

If all property constraints are exactly the same then you can theoretically write

rf:topic-properties a sh:PropertyShape ;

  sh:path [ sh:alternativePath ( rf:description rf:header ) ] ;

   ...

Note that any such abbreviation will mostly make sense to validation engines, but not necessarily to other tools. For example, if you wrap the sh:datatype constraints into a NodeShape then some algorithms such as forms builders will not discover that this constraint even exists.

Holger

--
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/f2b73447-40e5-46fc-a005-a3f04127f8a6n%40googlegroups.com.

[Emmanuel Oga]

oh! lots of ideas, thx so much!

E.