Re: Shapes vs Classes (in LDOM)

First of all, great work initiating this Holger!!!

Maybe I miss something in the semantics of the class declarations but I
would suggest a simplification of the constraint definitions. Examples:

# class example

ex:constraintA
  a ldom:ClassConstraint ;
  ldom:class ex:ClassA, ex:ClassB, ex:ClassC ; #  (oslc:describes)
  ldom:sparql """ ..?this ... """ ;
  ldom:property [
            ldom:predicate ex:propA ;
            ldom:minCount 1 ;
        ] ;

in this case, all classes (A,B & C) have a min cardinality 1 restriction on
ex:propA which is not possible if we subclass the constraint to a single
class.
We also decouple the schema declaration with the constraint declaration (*)

# global constraint example, the rdfs:Resource / owl:Thing declaration is
redundant

ex:constraintB
  a ldom:GlobalConstraint ;
  ldom:sparql """ ... """ ;

# ShExC / RS shapes in a similar way these are currently defined
ex:constraintC
  a ldom:ShapeConstraint ;
  ldom:sparql """ ... """ ;
  ldom:property [
            ldom:predicate ex:propA ;
            ldom:minCount 1 ;
        ] ;

For the ShapeConstraints we can define how validation can performed e.g.
starting from a node or inferring the types of the nodes based on the shape
definition and then validating in a similar way to the ClassConstraint.
Would something like this solve the class/shape problem?


(*) Another reason for not defining constraints as classes is that
automated Agents try to profile datasets for classes / properties used
which, might confuse them and give false statistics.

Best,
Dimtiris


On Fri, Jan 23, 2015 at 5:57 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas