RE: Can Shapes always be Classes?

My interpretation was to have two constraints (on both classes) to ensure
that if there is an instance of one, than there is an instance of the other.

This wouldn't cover the case where there are no instances of either class
e.g., the graph is empty or contains resources that are instances of some
other classes. 

The question is then, if such requirement is in scope. To me it is a trivial
case that is best handled at the application level. Meaning that the
constraint specification should say what shape the data must take when it
exists, not that it should exist.

If, however, this requirement is accepted, then, arguably, one could say
that there must be a way to specify what data should not be there - for
example, that there should be no instances of any other class whether they
are related to instances of the required classes or not. 

Personally, from the use case perspective I don't see either of this as
particularly useful or necessary.

Irene

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



On 11/5/14 10:58 AM, Irene Polikoff wrote:
> 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.

Actually, what it says is:

"If a Cultural Heritage Object is described in EDM, two classes must be used
for every provided object:

- edm:ProvidedCHO
- ore:Aggregation

Exactly one instance of rdf:type edm:ProvidedCHO and one instance of
rdf:type ore:Aggregation. The property edm:aggregatedCHO (domain
ore:Aggregation, range edm:ProvidedCHO) links them."

For every object (which is not edm:ProvidedCHO, but an identified
resource) there must be one edm:ProvidedCHO and one ore:Aggregation.

Your interpretation would be based on the existence of class
edm:ProvidedCHO, but that is not how it is worded.

kc



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

--
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 20:16:59 UTC