- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 5 Feb 2015 10:32:07 -0500
- To: Jose Emilio Labra Gayo <jelabra@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Jose, I agree with *almost* everything in your email. I disagree with your conclusion though. > On 5 Feb 2015, at 08:54, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote: > > - In the simplified example you have three classes: Person, Issue and Bug and you define > the classes/shapes in a single step with their corresponding constraints. However, in practice, if that example went to the open world web, it would not be that simple. > > - There could be some ontologies defining the concepts of Person, Issue and Bug which would probably be using RDFS or OWL. The stakeholders that define these ontologies would be using the domain of those concepts: in the case of a Person, they could say, for example, that a Person has two parents, has some weight, etc. Do you assume that the stakeholders defining reusable ontologies would *not* be using shapes to define the ontologies? Would you agree that some ontologies (e.g., SKOS and the RDF Data Cube Vocabulary) would be made better by including shape-style constraints in the definitions of the ontology? (I do agree that data publishers who use these ontologies may well want to include *additional* constraints to describe the particular way in which they use these ontologies, like you described.) > - Although in some closed systems, shapes can be attached to classes, when you want to publish data portals and have reusable classes and data, those are clearly two different concepts. You make it sound like attaching shapes to classes is something that one would only want to do in closed systems. I disagree with this. I expect that ontologies designed for use in open systems will also include shapes in their definitions. I know I would have liked to include some in several ontologies that I’ve worked on. > - […] we should not force future systems to couple shapes with classes when they don't need to be coupled. We should also not force future systems to decouple shapes and classes when they don’t need to be decoupled. Best, Richard
Received on Thursday, 5 February 2015 15:32:37 UTC