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

-- 
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 19:33:15 UTC