Re: using classes to control constraints

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah, but the business process constraints may also require that managers be
disjoint from executives in some division whereas in general managers can
also be executives, or require that executives be managers whereas in
general there are executives that are not managers, or require that phone
numbers be nine digits whereas in general they are strings, or require any
number of things that are not true in general.  Picking on cardinalities
just obscures the rest of the message.

peter


On 02/10/2015 05:48 AM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-10
> 04:27-0800]
>> 
>> 
>> On 02/10/2015 03:59 AM, Eric Prud'hommeaux wrote:
>>> 
>> [...]
>>> 
>>> 3/ There is some wording that introduces the notion of verifying that
>>>  sufficient information is present so that useful things can be done
>>> with
>>> 
>>>> the
>>> RDF data.
>>> 
>>>> I think I can address this with a "record class" as described in 
>>>> <http://www.w3.org/2015/02/shapes-article/> (many thanks for your 
>>>> feedback on that document).
>> 
>> Better but I still don't understand why you are picking on
>> cardinalities.
> 
> I believe they're the most direct example of how business process 
> constraints differ from ontological constraints. My business process may
> require exactly one email address for a customer in the orders database,
> but those sharks over in marketing may keep every email address they've
> ever seen for you in order to better meet your spam needs. The
> myCo:Customer has n email addrs; its use in Orders has 1.
> 
> 
>>> 4/ A set of constraints/shapes are given whose effect is that if the 
>>> data correctly validates the bug instances do indeed have sufficient
>>>> information.
>>> These constraints/shapes are triggered off the bug class.
>>> 
>>>> http://w3c.github.io/data-shapes/data-shapes-primer/no-class-templates.html#associations
>>>>
>>>>
>>
>>>> 
now includes a whole slew of associations with shapes,
>> 
>> 
>> That's looking better.  I would change the section heading to something
>> more like "Controlling Shape Validation"
> 
> I'm sympathetic to the intent, but I expect resistance from folks who 
> want to drive user interfaces or advertise data with shapes.  I think 
> that defining the validation behavior addresses all of the other needs 
> but we also want folks to reallize that we're meeting them.
> 
> 
>> and limit "instance" to where you are talking about instances of
>> classes, using "object" or "node" elsewhere.
> 
> done
> 
> 
>> the first of
>>>> which is ldom:instanceShape, second is ldom:classShape (editorially
>>>>  made sense in that order).
>>> 
>>>> [[ clinic:PatientRecord a owl:Class ; ldom:classShape [
>>>> ldom:property [ ldom:predicate clinic:phone ; ldom:valueType
>>>> xsd:string ; ldom:minCount 1 ; ldom:maxCount 1 ] ] . ]]
>>> 
>>>> Is that good enough for an FPWD to tell the world what we're up
>>>> to?
>>> 
>>> 
>>> I believe that this example satisfies all your desiderata above.
>>> 
>>> peter
>>> 
>>> 
>>> 
>>> 
>>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU2hazAAoJECjN6+QThfjzXnQH/R1yP6txmVvQD5myIY+qaQb8
asV04qTO0gwQlpTpp0VYwdgQnq+0LRN2bv+yE1uK5I1PDUzCpimok3chStqQ/+rQ
IWPaazDLWlk5hLc7LF0u5tDU7ze/nEsKJ1CkPxwU/QM09ClmI6/4zeMgp7N0gLYb
9SkKY7ZE41orfYYeT+PweDc9FgoZIUWiYrqjBR15XFl/Sx3+zO056Nsf97T1h+HS
3jvlRxYgXMUtA3WDT+QhKopiZeXk1gz4hA6+NEFNTcoilFsBFWHgMnWb9N5SlVKm
Ulzv1G5zoUZX0kZ9zzMfW25d8bJL/sUU7NeiJ9wwDh7bZBQLkQOqiNFjiSg0DXE=
=B3Kc
-----END PGP SIGNATURE-----

Received on Tuesday, 10 February 2015 14:33:54 UTC