ISSUE-5: Resource Shape Association

This page is about the various mechanisms to associate an RDF node (or set of RDF nodes) with shapes. The main goal of this linkage is to make sure that a constraint checking engine has enough information to figure out which conditions to validate. Another goal is to provide structural information that can be used for other purposes, in particular to learn "which properties are relevant" for a given node and what are the characteristics of those properties.

Issue 5 is concerned with this mechanism.

This page is not about determining which set of shapes are to be used to validate an RDF graph. That topic is covered by Graph Shape Association.

Different Ways of Associating Constraints or Shapes with RDF Nodes

Constraints at Classes

In this scenario, Shapes are associated with Classes, and the rdf:type predicate is used to link a given RDF node with a shape.

Example:

   ex:Person
       a rdfs:Class ;
       :property [
           :predicate ex:parent ;
           :valueType ex:Person ;
       ] ;
   .

To get a list of all constraints to validate for ex:MyPerson, follow the rdf:type link and look at all constraints associated with the classes and their superclasses. To learn about relevant properties (if someone wants to fill in a form for ex:MyPerson), follow the rdf:type link to get all :property declarations at the class and its superclasses.

Notable implementations of this paradigm include part of OWL constraints and SPIN (spin:constraint).

Resource Shapes 2.0 also define the property oslc:describes which binds a Shape to a rdfs:Class:

   ex:Person a rdfs:Class .
   ex:PersonShape
       :describes ex:Person;
       :property [
           :predicate ex:parent ;
           :valueType ex:PersonShape ;
       ] ;

Both examples above can validate the following RDF Graph

   ex:MyPerson
       a ex:Person ;
       ex:parent ex:MyMother ;
       ex:parent ex:MyFather ;
   .
   ex:MyMother a ex:Person .
   ex:MyFather a ex:Person .

Constraints for Evaluation purposes only

It may sometimes not be desirable to use rdf:type as in the scenario above, e.g. because it is only meant to apply in a certain context and we don't want to mix the "real" data model with constraint checking meta-data. For example to say that someone is a Person but he is also expected to fulfill the constraints of MalePerson.

This can be addressed by introducing a new property that is similar to rdf:type (I believe this is done by Resource Shapes 2.0). Here, the property :instanceShape points to instances of :Shape, not rdfs:Class

   ex:MyPerson
       a ex:Person ;
       :instanceShape ex:MalePerson ;
   .

Another approach that is compatible with current OWL/SPIN implementations would be to split the type triples into different named graphs or payloads:

   # Main graph
   ex:MyPerson
       a ex:Person ;
   .
   
   # Auxiliary graph for constraint checking
   ex:MyPerson
       a ex:MalePerson ;
   .

Constraints on the shape of a value

Sometimes it is beneficial to formalize the shape of nodes in a context-sensitive way, especially for values of properties in the context of another shape. Example:

   ex:Person
       :property [
           :predicate ex:parent ;
           :valueType ex:Person ;
           :minCount 2 ;
           :maxCount 2 ;
       ] ;
       :constraint [
           a :ShapeConstraint ;
           :predicate ex:parent ;
           :some ex:MalePerson ;
       ] ;
       :constraint [
           a :ShapeConstraint ;
           :predicate ex:parent ;
           :some ex:FemalePerson ;
       ] ;

which means that every Person must have two (biological) parents, one male and one female. Resource Shapes has a related property oslc:valueShape, which means that all values of a property need to match the given shape, so it could not express the above scenario. The Resource Shapes overview illustration implies that the domain of oslc:valueShape is oslc:Resource, meaning that it's a mechanism to connect the shapes in a particular schema and is not used to connect instance data to a schema - ericP

ShEx Mechanism

ShEx schemas can be associated with resources using the Resource Shapes predicates:

• { SHAPE oslc:describes TYPE . RESOURCE a TYPE . }
• { RESOURCE oslc:instanceShape SHAPE . }
• { SERVCE oslc:resourceShape SHAPE . } + a GRAPH with a RESOURCE submitted to or retrieved from SERVICE. (This is really a ternary relation involving some selection criteria for picking the RESOURCE from GRAPH, rendering the graph a rooted graph).
• API parameter passing: most ShEx interfaces allow both shape matching over all nodes and shape verification of a set of nodes enumerated in the invocation.

Constraints association on validation execution (No Linking)

It might be also useful to select the (set of) constraints on the validation execution. The user may explicitly select the desired constraints for the validation e.g.

validate RDFGraphA against C1,C2,C3

or select a set RDF graphs that contain constraints

validate RDFGraphB against Shapes in CG1,CG2,CG3

Graph Association: No Linking

DK: This is actually the exact No Linking case but it would be good to have it here for completeness

Based on decorations

Another approach would be to decorate shapes and associate them with an RDF Graph either explicitly or indirectly

   ex:PersonConstraint
       :decoration ex: , ex:label1 .
   # constraints omitted for brevity

These approaches are used in RDFUnit

Indirectly

An indirect approach for the validation engine would be to match the decorations with the namespaces in the RDF Graph to be validated. The approach would be to search the RDF Graph for all used namespaces (i.e. ex:) and then search for Constraints with that decoration. If the Constraints are stored in a different RDF graph from the data, the user will need to provide that RDF Graph to the validation engine or the validation engine will be able try to deference the Constraints with a follow-your-nose approach

Graph Association: Implicit Linking or Constraint selection in Embedding

Explicitly

The user may select the desired shapes for the current execution e.g.

validate RDFGraphA against Constraints decorated with ex:label1 [in ConstraintsGraph]

Graph Association: No Linking or Constraint selection in Embedding