- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Thu, 10 Jul 2014 11:29:15 -0400
- To: "Peter F. Patel-Schneider" <Peter.Patel-Schneider@nuance.com>
- Cc: public-rdf-shapes@w3.org
* Peter F. Patel-Schneider <Peter.Patel-Schneider@nuance.com> [2014-07-10 07:12-0700] > > From: Eric Prud'hommeaux <eric@w3.org> > >Date: Mon, 7 Jul 2014 19:11:47 -0400 > >To: Holger Knublauch <holger@topquadrant.com> > >Cc: public-rdf-shapes@w3.org > >Message-ID: <20140707231145.GD19116@w3.org> > > > [...] > > > >I think Arthur's point about separating schema from data was just > >that, if you want re-use of data, you can't attach your structural > >constraints to the types of the nodes. We don't want everyone who uses > >a foaf:Person to have to follow the same rules about whether or not > >their application permits/requires a givenName, an mbox, etc. Nor do > >we want it that a node can only serve one purpose, e.g. that some node > >can't act as both a User and an Employee [UEMP]. > > > > Huh? > > What then do you attach your structural constraints to? You attach structural constraints to the usage of a node in a particular context. Taking a simple example from the ShEx demo, <http://w3.org/brief/Mzc4>, we can see [[ <Issue1> ex:reportedBy <Thompson.J> ; ex:reproducedBy <Thompson.J> . ]] which means that <Thompson.J> must fulfill the requirements of both <UserShape> and <EmployeeShape>. This makes the validation "context-sensitive", which *might* be compilable into context-free if you detected all of the shapes that were compatible with other shapes, but I wouldn't count on it. > Perhaps you meant to say that having structural constraints and > ontology definitions in the same document is not a good idea. I can > go along with that, but what is wrong with having the ontology > definitions say that people have children and your structural > constraints say that people have at most fifty different children? > (Yes, a silly example.) (but borderline workable). Supposed day care patrons can have up to 50 children before being declared completely bananas. Those with 2 or more kids get tapped to take the kids on outings. schema: <DayCareShape> { :patron <PatronShape> ; :aid <AidShape> } <PatronShape> { :hasChild <ChildShape>{1,50} ; :creditCardNumber xsd:string } <AidShape} { :hasChild <ChildShape>{,2} } data: <GacyDayCare> :patron <Bob>, <Sue> ; :aid <Amy>, <Bob> . <Bob> :creditCardNumber "1234-5678" ; :hasChild <BobJr> . Not every patron is an aid and visa versa. If we demanded that Bob have extra type arcs to enumerate the roles he might play, we'd be awash in vapid type arcs and our system would require continuous maintenance of type assertions whenever someone was referenced in another capacity. It would be possible to tie ranges to e.g. :patron and :aid, but you wouldn't want to require that those type arcs be expressed in the data to be validated. You could put those type arcs off to the side, but then you've effectively implemented ShEx. > 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 Thursday, 10 July 2014 15:29:18 UTC