Re: Can Shapes always be Classes?

On 11/6/2014 5:32, 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.

I think the wording above is a bit confusing, because it is not about 
the existence of the *classes* (e.g. org:Aggregation rdf:type owl:Class) 
but rather the existence of instances of those classes (e.g. my:CHO a 
edm:ProvidedCHO).

If that is the case then can the first scenario not be easily expressed 
with either SPIN or OWL, e.g.

edm:ProvidedCHO
     rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty edm:aggregatedCHO ;
         owl:cardinality 1
     ]

So, if a ProvidedCHO exists then it must have an aggregatedCHO, which 
(as stated in an allValuesFrom or range restriction) must be an instance 
of Aggregation.

I do not understand the second scenario yet - "an identified resource". 
How is that identified? SPIN provides the concept of global constraints 
that are attached to owl:Thing or rdfs:Resource, and this can be used to 
check for arbitrary other patterns, e.g. to check whether a given class 
has any instances at all (or attach it as a spin:constraint to the 
metaclass).

So I am not seeing how this demands detaching constraints from classes.

Holger


>
> 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 23:18:17 UTC