Re: shapes and classes: different

Jose, thank you for this. I, too, have concerns about the interplay of 
the open and closed environments for my data. I have asked, perhaps not 
clearly enough, whether the use of validation based on classes could 
require me to use two different ontologies - one for the closed world, 
and one for the open one. I don't want to associate properties or graphs 
with classes unless those classes reflect the semantics of my open world 
data. I would rather provide an application profile for my closed world 
that defines my closed world semantics without modifying the open world 
semantics that serve me best.

I believe that to implement this, shapes that are not necessarily 
defined as rdf:type will be needed. I also see a utility in sub/super 
relationships that has not been discussed. I will try to find some 
documentation of how that is being envisioned for bibliographic data, 
and will post links here.

kc

On 2/5/15 5:54 AM, Jose Emilio Labra Gayo wrote:
> 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

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 5 February 2015 15:11:17 UTC