Re: Constraints on classes

HmmŠ I was thinking that the way to express the constraint that each CHO
must have a corresponding aggregation would be something like:

edm:CHO 
sh:property [
sh:inversePredicate edm:aggregatedCHO ;
sh:valueType ore:Aggregation ;
sh:minCount 1 ;
] .

I am just making up how a statement about an inverse property may look
like. This would mean that each CHO must have an incoming link from some
aggregation.

Below, on the other hand, says that every aggregation must identify a CHO.

ore:Aggregation
     sh:property [
         sh:predicate edm:aggregatedCHO ;
         sh:valueType edm:CHO ;
         sh:minCount 1 ;
     ] .




Regards,

Irene 






On 4/25/15, 6:15 PM, "Holger Knublauch" <holger@topquadrant.com> wrote:

>
>
>On 4/26/15 2:37 AM, Karen Coyle wrote:
>> Holger, I think I explained it clearly, although not in words that you
>> would use. We can't all be you, after all.
>
>I am just trying to use standard RDF terminology.
>>
>> So I attach an actual file.
>
>That's better. Does the following express what you need then?
>
>ore:Aggregation
>     sh:property [
>         sh:predicate edm:aggregatedCHO ;
>         sh:valueType edm:CHO ;
>         sh:minCount 1 ;
>     ] .
>
>(Assuming edm:ProvidedCHO rdfs:subClassOf edm:CHO).
>
>Holger
>
>>
>> kc
>>
>> On 4/24/15 7:19 PM, Holger Knublauch wrote:
>>>
>>>
>>> On 4/24/15 11:56 PM, Karen Coyle wrote:
>>>> I've been trying to understand if this is covered by existing
>>>> requirements or not...
>>>>
>>>> The Dublin Core set of requirements for application profiles
>>>> (including validation)[1] has some constraints based on classes (read:
>>>> rdf:type) not properties. For example,
>>>>
>>>> - For every node/graph of type edm:CHO there must also be a linked
>>>> node/graph of type ore:Aggregation.
>>>
>>> Could you clarify what you mean with "node/graph"? Do you assume a
>>> certain architecture in which each subject resource lives in its own
>>> graph? Also, is the property known or is it "any" (wildcard) linked
>>> property? If it's a known property, and assuming you mean "node"
>>>instead
>>> of "graph" then this could be expressed via
>>>
>>> edm:CHO
>>>      sh:property [
>>>          sh:predicate edm:someProperty ;
>>>          sh:valueType ore:Aggregation ;
>>>          sh:minCount 1 ;
>>>      ] .
>>>
>>>>
>>>> - For every node/graph of type ex:Book there can be 0..n linked nodes
>>>> of type ex:Author, but no nodes of type ex:Composer.
>>>
>>> You didn't provide enough information to model this. Do you have two
>>> properties ex:author and ex:composer, or are they all values of the
>>>same
>>> property? In the former case this could be:
>>>
>>> ex:Book
>>>      sh:property [
>>>          sh:predicate ex:author ;
>>>          sh:valueType ex:Author ;
>>>      ] ;
>>>      sh:property [
>>>          sh:predicate ex:composer ;
>>>          sh:maxCount 0 ;
>>>      ] ;
>>>
>>> (or maybe also sh:constraint sh:ClosedShape instead of the ex:composer
>>> restriction).
>>>
>>> HTH
>>> Holger
>>>
>>>>
>>>>
>>>> I asked this many moons ago and was assured that it was included in
>>>> the existing requirements, but if it's there I haven't identified it.
>>>> Is this covered, or do I need to add a story+requirement proposal?
>>>>
>>>> BTW, we are doing an analysis comparing the DCMI requirements with
>>>> this group's requirements. This is one of the more significant gaps.
>>>>
>>>> Thanks,
>>>> kc
>>>>
>>>>
>>>> [1]
>>>> 
>>>>http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Requireme
>>>>nts 
>>>>
>>>>
>>>
>>>
>>>
>>
>
>

Received on Sunday, 26 April 2015 02:00:28 UTC