RE: Can Shapes always be Classes?

Holger,

I believe you are saying that there could be two (or more) named graphs each
containing different sets of constraints for a particular classes (or
classes). For example:

Graph A: contains rdf:type statements for a set of classes and properties.
Can also contain other RDFS or OWL axioms

Graph B: contains some constraints for classes declared in Graph A

Graph C: contains a different set of constraints for classes declared in
Graph A

And so on

A given application can then chose what set of constraints it will be using
- Graph B or Graph C.

Is this correct?

Irene

-----Original Message-----
From: Holger Knublauch [mailto:holger@topquadrant.com] 
Sent: Wednesday, November 05, 2014 12:16 AM
To: public-data-shapes-wg@w3.org
Subject: 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:26:42 UTC