- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Thu, 31 Jul 2014 16:16:23 -0400
- To: "Peter F. Patel-Schneider" <Peter.Patel-Schneider@nuance.com>
- Cc: <public-rdf-shapes@w3.org>
Peter, 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] [1] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#associating-and-applying-shapes Regards, ___________________________________________________________________________ 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" <Peter.Patel-Schneider@nuance.com> To: <public-rdf-shapes@w3.org>, Date: 07/10/2014 10:19 AM Subject: Re: ShEx relation to SPIN/OWL > 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? 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.) peter
Received on Thursday, 31 July 2014 20:16:54 UTC