Re: ShEx relation to SPIN/OWL

* 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