Re: ShEx relation to SPIN/OWL


If you intend a vocabulary or ontology to be reused in other applications, 
then you should define only the bare minimum of constraints (or inference 
rules) in it. Then the other applications have to define how they are 
using your terms.

We used a couple of mechanisms for associating constraints at OSLC. 
1) a REST API service description may link to a shape. The service defines 
the API contract for how resources are created, modified, and retrieved
2) a resource may link to a shape

This is described at [1]


Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)

From:   "Peter F. Patel-Schneider" <>
To:     <>, 
Date:   07/10/2014 10:19 AM
Subject:        Re: ShEx relation to SPIN/OWL

>  From: Eric Prud'hommeaux <>
> Date: Mon, 7 Jul 2014 19:11:47 -0400
> To: Holger Knublauch <>
> Cc:
> Message-ID: <>
> 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].


What then do you attach your structural constraints to?

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 
have children and your structural constraints say that people have at most 

fifty different children?  (Yes, a silly example.)


Received on Thursday, 31 July 2014 20:16:54 UTC