RE: Can Shapes always be Classes?

I read UC-5 as saying that for each instance of - edm:ProvidedCHO there must
be exactly one instance of  ore:Aggregation connected to it using
edm:aggregatedCHO - and vice versa. To me this is a class level constraint.


-----Original Message-----
From: Karen Coyle [mailto:kcoyle@kcoyle.net] 
Sent: Wednesday, November 05, 2014 9:25 AM
To: public-data-shapes-wg@w3.org
Subject: Re: Can Shapes always be Classes?



On 11/4/14 9: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.

The Dublin Core DSP [1] defines stand-alone entities that resemble named
graphs, not classes. The main motivation was NOT different shapes and
different times, although I do not know what the main motivation was. 
The DC work that led to it [2] preceded RDF and simply did not include
types. That said, some DC use cases look to me like constraints on named
graphs, not classes. For example, UC-5 validates for the presence of
mandatory classes within a graph. [3]

kc
[1] http://dublincore.org/documents/dc-dsp/
[2] http://dublincore.org/documents/abstract-model/
[3]
http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=UC-5-MANDATORY-
EDM-CLASSES

>
> 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
>
>
>

--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 5 November 2014 18:58:57 UTC