Re: Shapes vs Classes (in LDOM)

I am in no way saying that your proposal is wrong, I am just suggesting my
idea for separating distinct validation types (class, global, shape).
(only one comment inline)

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

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

I saw that in an OSLC example document and liked the idea.


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


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