W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: ShEx relation to SPIN/OWL

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 10 Jul 2014 09:17:15 -0700
Message-ID: <53BEBC8B.3020806@gmail.com>
To: Eric Prud'hommeaux <eric@w3.org>
CC: public-rdf-shapes@w3.org

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.

Received on Thursday, 10 July 2014 16:17:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC