Re: shapes and classes: different

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

Instances of RDF classes such as ex:Person are also represented in RDF 
graphs. I don't think this is a sufficiently strong distinction between 
Shapes from Classes (apart from maybe philosophical considerations). 
Could you clarify why you believe this is relevant in practice?

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

First, neither would an indirect linkage between classes and shapes help 
(e.g. ldom:classShape). This would just shift the problem by one step.

Second, there are other mechanisms to achieve the modification scenarios 
that you describe.
- Manually triggering a start shape (as done in ShExC, outside of the 
RDF model)
- Adding more information to existing classes via named graphs
- Creating subclasses
- Selecting which constraints to use and not use via ldom:context

The latter especially seems to cover a large number of use cases that 
originally motivated the separate concept of "shapes". I would welcome 
more real-world examples so that we can compare the various options and 
don't have to fall back to vague statements that amount to personal taste.

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

I would invite the stand-alone Shapes supporters to provide stronger 
evidence for their view point. Classes are already well-established, and 
easy to understand for most people in and outside of the RDF world. If 
something else is needed, then there need to be strong arguments for 
that. I am very much trying to find a compromise. But whenever I drill 
into examples, there seems to be a class-based solution that would work 
just as well.

Holger

Received on Thursday, 5 February 2015 22:26:20 UTC