- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Fri, 24 Apr 2015 09:02:33 -0700
- To: kcoyle@kcoyle.net, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
-----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