Re: Shapes vs Classes (in LDOM)

On 1/23/15, 7:03 PM, Dimitris Kontokostas wrote:
> 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.

Hi Dimitris,

to me this looks like the wrong direction. It is much more natural to write

ex:ClassA
     ldom:property [
         ...
     ]

Sharing the same property across multiple classes is also not a scenario 
that I have come across yet. And why the extra burden of creating a URI 
for the constraint - I guess most people will be perfectly happy with 
blank nodes. Likewise, why should they have to explicitly declare the 
type ldom:ClassConstraint, if it is implicit from the context.

> We also decouple the schema declaration with the constraint 
> declaration (*)

I don't think this decoupling is often desirable. When someone defines a 
class, then of course the properties should be defined together with it 
(just like owl:Restrictions did). What else would a class definition 
good for?

In case someone really has to define shapes independently from classes, 
then we can easily add a property such as the inverse of the ldom:class 
that you have above, e.g. ldom:shape as in

ex:ClassA
     ldom:shape ex:ShapeB ;

This would offer the same flexibility but have it in a more natural 
direction to cover the most common use cases.
>
> # 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?

Why would the solution that I proposed not work?

Thanks,
Holger


>
>
> (*) 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 <mailto: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