Re: Constraints on classes

-----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-----

Received on Friday, 24 April 2015 16:03:09 UTC