Re: shapes and classes: different

After reviewing the Classes and Shapes example I have some comments:

- I think it is interesting to play with a simplified example so we can
understand better
 the implications of the different approaches.

- However, the example goes too far in the simplification direction because
it assumes a closed environment where the model is being done once, maybe
by the same person at some specific point in time.

- Although it can be useful in controlled environments, it does not scale
well to
the open web where ontologies are created by some group of people at one
time, data portals are created by another group of people with other
technical skiills at other times, and data aggregators of those ontologies
and data will be created at other times by other groups of people.

- The problem is that all those systems will probably be created by
different stakeholders with different skills, purposes and goals.

- 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.

- Later, some people defining data portals would define the RDF graphs that
their data portals are employing. For example, an English data portal could
add the declaration that an Issue has an rdfs:label literal in English,
while an Spanish one, would say that rdfs:label should be in Spanish. The
stakeholders that define those data portals are probably developers which
are interested in their RDF graphs as an interface. They are not talking
about People, they are talking about Shapes of People (represented as RDF
graphs).

- There could be data portal consumers later, which would be interested to
collect information about the published issues from those data portals.
Here again, the stakeholders are developers which are interested in the
shapes of those RDF graphs. For example, they need to know that there is an
rdfs:label property in one language or the other to represent the issues
accordingly. They are talking again about shapes, not classes.

- Even later, there could be some other people who want to collect the
information from those aggregators and to combine that information with
other information to do some reasoning. Here, that people could raise the
abstraction level to talk again about the concepts (People, Issues, etc.)
and they will again be interested in concepts and doing some reasoning
using those concepts, not their shapes. That people wants to recover the
classes without their shapes, because the shapes in those data portals
preclude them to reuse those classes in other contexts. This concept of
reusable classes is important and cannot be obtained if you couple shapes
with classes.

 - From my point of view there is a separation of concerns between the
goals and needs of the stakeholders interested in classes and the
stakeholders interested in shapes.

 - 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.

 - I propose to concentrate in the definition of a language that enables
the definition of shapes, and some mechanism to associate shapes with RDF
graphs. If you want, one of those mechanisms could be rdf:type, so one can
validate all instances of some specific class against some shape, but there
could be other mechanisms. In this way, we may support already deployed
systems, but we should not force future systems to couple shapes with
classes when they don't need to be coupled.

Best regards, Jose Labra