oh! lots of ideas, thx so much!

E.

On Thursday, October 15, 2020 at 12:15:33 AM UTC-7 Holger Knublauch wrote:

> 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 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
>  
> <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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/ab96fbac-db26-40df-ac6e-aeda5c052f8an%40googlegroups.com.

Reply via email to