- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 05 Nov 2014 15:13:15 -0800
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-data-shapes-wg@w3.org
That's how I read it. - kc On 11/5/14 2:34 PM, Peter F. Patel-Schneider wrote: > 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 >>> >>> >>> >>> >> > -- 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:13:45 UTC