Re: using classes to control constraints

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-10 06:33-0800]
> 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.

Understood. I'll try to tighten that up tomorrow.


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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Tuesday, 10 February 2015 15:07:51 UTC