Re: Constraints on classes

OK, thanks. I'll take that as a yes, and when we get to use cases I'll 
make sure to include some that are convincing. ;-)

kc

On 4/24/15 9:02 AM, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> If you mean things like "every US taxpayer has to have a name, and at most
> one spouse, and either exactly one SSN or exactly one TIN" then I think that
> your use case is covered.  What you want is selection "every US taxpayer"
> and then a shape (maybe a complex shape).  The requirement covers the
> selection and the other stuff is covered by the general shape requirements.
>
> peter
>
>
> On 04/24/2015 08:54 AM, Karen Coyle wrote:
>> Thanks, Peter. I think my use case goes beyond this one, because this one
>> is defined as a simple selection by type[1], and I need to actually
>> constrain types:
>>
>> - in relation to each other (and/or/not) - using cardinality
>>
>> I think this needs to be a "complex constraint" similar to the complex
>> constraints that are defined for properties. We could expand this
>> requirement, or, if it seems to be a better idea, we could expand the
>> complex constraints on property to include either property or type. Then
>> again, there is the possibility of a separate requirement. ? Comments?
>>
>> kc [1] " R12.2: Selection by Type
>>
>> It should be possible to have some mechanism to select the nodes that
>> are instances of some class for validation. "
>>
>>
>>
>> On 4/24/15 7:38 AM, Peter F. Patel-Schneider wrote: I believe that
>> approved requirement 2.12.2
>> http://www.w3.org/2014/data-shapes/wiki/Requirements#Selection_by_type
>> covers these situations.   User story S2 is based on selection by type.
>>
>> Both SPIN and Stardog ICV can do this, as can both of the SPARQL-based
>> proposals.  I don't believe that Shape Expressions can do this without
>> having bare negation.  As far as I can tell, Resource Shape 2.0 can't do
>> this, although I  remain confused as to how Resource Shape 2.0 works.
>>
>> peter
>>
>>
>> On 04/24/2015 06:56 AM, Karen Coyle wrote:
>>>>> I've been trying to understand if this is covered by existing
>>>>> requirements o
>> r
>>>>> 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/grap
>> h
>>>>> of type ore:Aggregation.
>>>>>
>>>>> - For every node/graph of type ex:Book there can be 0..n linked
>>>>> nodes of typ
>> e
>>>>> ex:Author, but no nodes of type ex:Composer.
>>>>>
>>>>> 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/Requiremen
>>
>>>>>
> ts
>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVOmkZAAoJECjN6+QThfjzI1UIALCOYVT9F9OCvS0TyfBSoWh6
> IM0+rujrSAUoJeGzE/6/dKZFl68gK3Crt5t8coKd7YGqAeVcXZeibf/A5+e514Gf
> 0TuZ/siYF3HU9J3k06eljorP9r79UBVZNsiMazaTO6u74m6VUQZaMdO8xkkeMO+P
> vKbWtN72hMqUT2iwv73eFPbwMW90QtD+kuq+CQYBJ6WFMQk+SrnNneKEFzqEMlws
> 9dQVt9WTiVjs6/O6ZU186z8qhJSkpxKBnmKJiMNM+h/TG4Tk9V75a5zbc8g33ktU
> ov4zZUOAKdiS90kCSa6N+3tzVQmgvbNoa2hItf3R/HQ2dXsASQMwZ5RUIfPKLiA=
> =vBtu
> -----END PGP SIGNATURE-----
>

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

Received on Friday, 24 April 2015 16:06:43 UTC