Can Shapes always be Classes?

I believe there is a fundamental difference in how the various proposals 
treat the relationship between resources and their shapes:

- In OWL and SPIN, constraints are attached to classes. rdf:type triples 
are used to determine which constraints need to be evaluated for a given 
instance.

- In the original Resource Shapes and ShEx, Shapes are stand-alone 
entities that may or may not be associated with a class. Other 
mechanisms than rdf:type are used to point from instances to their shapes.

I believe the main motivation for the latter design are the User Stories 
S7 and S8: different shapes at different times, and properties can 
change as they pass through the workflow. I would like to learn more 
about this and have specific examples that we can evaluate.

My current assumption is that these scenarios can be expressed via named 
graphs, so that different class definitions are used in different 
contexts. Which graph to use would be specified in some kind of header 
metadata or via a special property (e.g. owl:imports). Alternatively, 
different classes could be used, just like different shapes are used 
depending on the context. I argue that using rdf:type and RDFS classes 
is a well-established mechanism that we should try to build upon. What 
problems do the proponents of the decoupling see with those ideas?

I think this is a major design decision that we need to clarify early. 
Instead of excluding those scenarios, I would like to accommodate them 
without having to introduce completely new mechanisms.

Thanks
Holger

Received on Wednesday, 5 November 2014 05:19:01 UTC