Re: Can Shapes always be Classes?

On 11/5/2014 15:26, Irene Polikoff wrote:
> 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?

Yes sorry I was brief. Let's take an extreme use case, where the same 
ex:Instance must fulfill different constraints in scenario A and B.

     ex:Instance
         a ex:Person ;
         foaf:firstName "John" .

Scenario A: Each Person can have any number of first names.

Scenario B: Each Person must have exactly one first name.

In scenario A, it would have

     <instance graph> owl:imports <schema A>

where <schema A> is simply the unconstrained class definition.

     ex:Person a rdfs:Class .

In scenario B, it would owl:import <schema B> which is

     ex:Person a rdfs:Class ;
         constraint foaf:firstName exactly 1 .

I hope this explains the named graph work-around.

Holger


>
> 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:38:12 UTC