Shapes vs Classes (in LDOM)

May I suggest we try to resolve the long-standing issue of Shapes versus 
Classes in the specific context of LDOM. Maybe we can make progress if 
we have a specific metamodel in front of us.

In the current draft, class definitions are containers of constraints, i.e.

     rdfs:Class
         a rdfs:Class ;
         rdfs:subClassOf rdfs:Resource ;
         ldom:property [
             ldom:predicate ldom:constraint ;
             ldom:valueType ldom:Constraint ;
         ] ;
         ldom:property [
             ldom:predicate ldom:property ;
             ldom:valueType ldom:PropertyConstraint ;
         ] ;

which means that you can define a class such as

     ex:Rectangle
         ldom:property [
             ldom:predicate ex:height ;
             ...
         ] ...

This could (easily) be generalized by moving the properties into a new a 
class

     ldom:Shape
         a rdfs:Class ;
         rdfs:subClassOf rdfs:Resource ;
         ldom:property [
             ldom:predicate ldom:constraint ;
             ldom:valueType ldom:Constraint ;
         ] ;
         ldom:property [
             ldom:predicate ldom:property ;
             ldom:valueType ldom:PropertyConstraint ;
         ] ;

  which serves as superclass of rdfs:Class

     rdfs:Class
         a rdfs:Class ;
         rdfs:subClassOf ldom:Shape ;

This would mean that users could define stand-alone shapes

     ex:MyShape
         a ldom:Shape ;
         ldom:property [
             ...
         ] ...

And this shape could be reused such as in

     ex:MyClass
         a rdfs:Class ;
         ldom:constraint [
             a ldom:ShapeConstraint ;
             ldom:all ex:MyShape ;
         ] ...

or as an entry point to the validation:

     FILTER ldom:violatesConstraints(?resource, ex:MyShape)

(maybe renaming the function above to ldom:hasShape).

Since rdfs:Class is a subclass of ldom:Shape, class definitions become 
special kinds of shape definitions. The main differences between classes 
and shapes would be:

- Classes can be instantiated, i.e. you can have ex:MyRectangle a 
ex:Rectangle
- Class-based constraints get inherited (Shapes cannot have rdfs:subClassOf)

I don't see practical problems with such a design, and in fact it may be 
a cleaner separation of concerns. The reason why these two concepts are 
currently merged into one is that the differences are fairly small, and 
people could simply define an anonymous (even typeless) class as a 
collection of constraints, as in Example 9

     http://spinrdf.org/ldomprimer.html#template-constraints

Thoughts?

Cheers,
Holger

Received on Friday, 23 January 2015 04:00:40 UTC