Re: Can Shapes always be Classes?

Two things to note about constraints being attached to classes:

1/ There is nothing in constraints being attached to classes that implies that 
constraints are part of an ontology.  Class-attached constraints can be 
separate from the ontology, and used when appropriate.  Several sets of 
class-attached constraints can be associated with classes from the same ontology.

2/ If classes can be defined, class-attached constraints can handle 
object-attached constraints and role-attached constraints.

peter


On 11/04/2014 09:16 PM, Holger Knublauch wrote:> 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 15:17:39 UTC