Re: Can Shapes always be Classes?

As this is not my use case, the best I can do is provide what I believe 
are the relevant snippets out of a very large file that I have on hand:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
xmlns:edm="http://www.europeana.eu/schemas/edm/">
   <edm:ProvidedCHO 
rdf:about="http://data.europeana.eu/item/9200231/BibliographicResource_2000092034263"/>

...
  <ore:Aggregation xmlns:ore="http://www.openarchives.org/ore/terms/" 
rdf:about="http://data.europeana.eu/aggregation/provider/9200231/BibliographicResource_2000092034263">

...
   </ore:Aggregation>
...
</rdf:RDF>

If you want to see the entire file, or at least a complete "record" I 
could provide that. If we could draw pictures in email this would all be 
easier, but I'm seeing:

<bibliographicResource_2000092034263>
    edm:ProvidedCHO [
          ... ] ;
    ore:Aggregation [
          ... ] .

I kinda doubt this helps.
kc


On 11/5/14 3:15 PM, Holger Knublauch wrote:
> 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
>>>
>>>
>>>
>>>
>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 6 November 2014 00:11:17 UTC