Re: ShEx relation to SPIN/OWL

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-07-10 09:17-0700]
> 
> 
> On 07/10/2014 08:29 AM, Eric Prud'hommeaux wrote:
> >* 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 less kids get tapped
> >to take the kids on outings.
> >
> >schema:
> >   <DayCareShape> {
> >     :patron <PatronShape> ;
> >     :aide <AideShape>
> >   }
> >   <PatronShape> {
> >     :hasChild <ChildShape>{1,50} ;
> >     :creditCardNumber xsd:string
> >   }
> >   <AideShape} {
> >     :hasChild <ChildShape>{,2}
> >   }
> >
> >data:
> >   <GacyDayCare> :patron <Bob>, <Sue> ;
> >                 :aide <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
> 
> 
> You want to express constraints based on, for example, a node being
> a value for a particular property *and* you don't want to use ranges
> to get a type to attach to, because you think that that would
> require some sort of special machinery.  Can you attach constraints
> to types at all then?
> 
> It does seem very strange to me that you have gone to so much work
> to essentially reinvent defined types, as in OWL, however.  Or maybe
> I'm missing something here.
> 
> 
> For example, you can recast the above example as something like
>   DayCare = all :patron Patron & all :aide Aide & E :patron & E :aide
>   Patron = all :hasChild Child & [1-50] :hasChild &
>            all :creditCardNumber xsd:string & E :crediCardNumber
>   Aide = all :hasChild Child & [,2] :hasChild
> You then model-check the minimal model of the data and any RDFS
> ontology used in the data against these OWL definitions.
> 
> This actually succeeds, because there is no starting point and no
> explicit typing in the data.  If you either add that <GacyDayCare>
> rdf:type DayCare to the data or have a requirement that some node
> matches <GacyDayCare> then you get a failure because Sue doesn't
> match Patron.

How does Sue fail to match Patron, is it because she fails a minimum
cardinality constraint on :creditCardNumber? If so, I expect you've
added NAF to OWL. Is the system doing type inference but not inferring
e.g. that Sue has a credit card number?

What I'm getting at is that a system that provides practical
validation of business (or scientific, or clinical) rules isn't
trivially available from OWL. Historically, there have been three
deployed systems filling this void: Dublin Core Application Profiles,
post-submission developments of spin:constraint, and OSCL Resource
Shapes. The last half year has seen three or four implementations of
ShEx, in part for the compact syntax (ShExC) and in part for the
expressivity. All of this time, RDF has attracted people with an eye
towards open world, far-sighted data integration, but has not offered
a serious alternative to XML because it offers no analogy to Relax NG
or W3C XML Schema.


> 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 18:59:01 UTC