W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Shapes vs Classes (in LDOM)

From: Holger Knublauch <holger@topquadrant.com>
Date: Sat, 24 Jan 2015 10:51:19 +1000
Message-ID: <54C2EC87.1090909@topquadrant.com>
To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
One more thing:

It would be very helpful to have specific examples of things that cannot 
be properly expressed with the current LDOM draft. I would like to ask 
those who support stand-alone Shapes to provide detailed shape 
declarations and corresponding instances that serve as grounding for 
this discussion.

Many thanks,
Holger



On 1/23/15, 8:42 PM, Holger Knublauch wrote:
> I think that separation of classes and types (and of course global 
> constraints) is fine - our differences are largely syntactical. I will 
> experiment with adding the class ldom:Shape and a property ldom:shape 
> that links a class with its (additional) ldom:Shapes and publish an 
> update, hopefully early next week. I think this will provide the 
> freedom of separating things (that is advocated by Resource 
> Shapes/ShEx), while at the same time supporting the pattern of 
> attaching constraints to classes (that is working well for SPIN 
> users). Users will be able to mix those types of declarations.
>
> Holger
>
>
> On 1/23/15, 8:05 PM, Dimitris Kontokostas wrote:
>> 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 <mailto: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 <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
>>
>>
>>
>>
>> -- 
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig
>> Research Group: http://aksw.org
>> Homepage:http://aksw.org/DimitrisKontokostas
>
Received on Saturday, 24 January 2015 00:51:52 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 24 January 2015 00:51:53 UTC