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
On 10/15/2020 3:59 PM, Emmanuel Oga wrote:
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.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/f2b73447-40e5-46fc-a005-a3f04127f8a6n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/f2b73447-40e5-46fc-a005-a3f04127f8a6n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/c4319788-e3a1-b986-afbd-0e8dc2fac944%40topquadrant.com.