Re: Can Shapes always be Classes?

As far as I can tell, the constraint that this is saying is that 
edm:ProvidedCHO and ore:Aggregation are co-extensional.  Is this right?

peter


On 11/05/2014 11:32 AM, Karen Coyle wrote:
>
>
> 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
>>
>>
>>
>>
>

Received on Wednesday, 5 November 2014 22:35:15 UTC