Specifying Range Types for a Property in a Form

[Steven Folsom]

My understanding is that the semantics of the following shape is that every individual related to a ex:Work through ex:subject must be a member of ALL of the classes listed. Am I wrong to think this?

sh:property [
      sh:path ex:subject ;
      sh:target ex:Work ;
      sh:class ex:Instance ;
      sh:class ex:Item ;
      sh:class ex:Temporal ;
      sh:class ex:Work ;
      sh:class ex:Event ;
      sh:class ex:Language ;
      sh:class ex:Concept ;
      sh:class ex:Location ;
      sh:class ex:Agent ;
] .

Based on the examples I've seen, using sh:in seems to be reserved for listing individuals. Am I wrong to think this? For example is it permitted to construct the following shape using sh:in for classes?

sh:property [
      sh:path ex:subject ;
      sh:target ex:Work ;
      sh:in ( ex:Work ex:Instance ex:Item ex:Temporal ex:Event ex:Language ex:Concept ex:Location ex:Agent ) ;

] .

My use cases are to be able to say in a dataset only these types of things can be the subject of a work AND to build a form that narrows the types of things that can be the subject of a ex:Work.

Any help to understand how to say these types of constraints using SHACL would be greatly appreciated.

Thanks,

Steven

------------

Steven Folsom
Metadata Specialist
Cornell University Library
http://orcid.org/0000-0003-3427-5769
http://vivo.cornell.edu/individual/sf433
@sf433

[Irene Polikoff]

On Sep 18, 2017, at 8:46 PM, Steven Folsom <sf...@cornell.edu> wrote:

My understanding is that the semantics of the following shape is that every individual related to a ex:Work through ex:subject must be a member of ALL of the classes listed. Am I wrong to think this?

sh:property [
      sh:path ex:subject ;
      sh:target ex:Work ;
      sh:class ex:Instance ;
      sh:class ex:Item ;
      sh:class ex:Temporal ;
      sh:class ex:Work ;
      sh:class ex:Event ;
      sh:class ex:Language ;
      sh:class ex:Concept ;
      sh:class ex:Location ;
      sh:class ex:Agent ;
] .

You need to use sh:targetClass

If you say

ex:MyNodeShape sh:targetClass ex:Work;

sh:property [
sh:path ex:subject ;

sh:class ex:Instance ;
sh:class ex:Item ;
sh:class ex:Temporal;
sh:class ex:Work ;
sh:class ex:Event ;
sh:class ex:Language ;
sh:class ex:Concept ;
sh:class ex:Location ;
sh:class ex:Agent ;
] .

You will indeed be saying that every resource that is an object of a triple where a subject is a member (transitively) of ex:Work and a predicate is ex:subject must be an instance (transitively) of all these classes.

Based on the examples I've seen, using sh:in seems to be reserved for listing individuals. Am I wrong to think this? For example is it permitted to construct the following shape using sh:in for classes?

sh:property [
      sh:path ex:subject ;
      sh:target ex:Work ;
      sh:in ( ex:Work ex:Instance ex:Item ex:Temporal ex:Event ex:Language ex:Concept ex:Location ex:Agent ) ;

] .

In your example, the property shape is contained within some node shape that you are not listing here. I am concluding this because you are using sh:property. In these cases, the target statement for the property shape will be ignored. See my example above as to how to use targets.

You can use anything in sh:in, but what you listing above says that the object of a triple with ex:subject predicate must be either ex:Work, ex:Instance, etc. Not that the objects must be of certain types.

You can do:

ex:MyPropertyShape

a sh:PropertyShape ;

sh:targetClass a ex:Works ;

sh:path (ex:subject rdf:type) ;

sh:in ( ex:Work ex:Instance ex:Item ex:Temporal ex:Event ex:Language ex:Concept ex:Location ex:Agent ) .

or

ex:MyNodeShape 

a sh:NodeShape ;

sh:targetClass ex:Work;
sh:property [

sh:path (ex:subject rdf:type) ;

sh:in ( ex:Work ex:Instance ex:Item ex:Temporal ex:Event ex:Language ex:Concept ex:Location ex:Agent ) 

].

The advantage of the second option is that you can then group together any other constraints that members of the ex:Work class may have e.g.,

ex:MyNodeShape 

a sh:NodeShape ;

sh:targetClass ex:Work;
sh:property [

sh:path (ex:subject rdf:type) ;

sh:in ( ex:Work ex:Instance ex:Item ex:Temporal ex:Event ex:Language ex:Concept ex:Location ex:Agent );

];

sh:property [

sh:path ex:author ;

sh:minCount 1;

].

etc.

If you want to also allow subclasses of ex:Work, ex:Instance, etc. and you do not want to list them explicitly, then you need to go with sh:class and use sh:or

sh:property [

sh:path ex:subject ;

sh:or (

[

sh:class ex:Work ;

]

[

sh:class ex:Instance ;

]

                       [ …]# your other classes

)

] .

My use cases are to be able to say in a dataset only these types of things can be the subject of a work AND to build a form that narrows the types of things that can be the subject of a ex:Work.

Any help to understand how to say these types of constraints using SHACL would be greatly appreciated.

Thanks,
Steven

------------
Steven Folsom
Metadata Specialist
Cornell University Library
http://orcid.org/0000-0003-3427-5769
http://vivo.cornell.edu/individual/sf433 
@sf433

-- 
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.

[Steven Folsom]

Thanks Irene, this response was very helpful! (particularly why one would could one pattern over another)

I am indeed working within a larger node shape with a sh:targetClass, but left that part out. Given that I want subclasses to be included, I'll opt for sh:or with sh:class, over sh:in. 

Thanks again.