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

Re: Shapes vs Classes (in LDOM)

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Fri, 23 Jan 2015 13:18:48 +0200
Message-ID: <CA+u4+a3bR7t+EA0XitKw34jnduoj-YhJxF8M0-hBJVgm4vrD5w@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
On Fri, Jan 23, 2015 at 12:42 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>  I think that separation of classes and types (and of course global
> constraints) is fine - our differences are largely syntactical.
>

I know and it is too early to argue on this further.

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

I would not be in favor of a mixed approach as this would complicate the
constraint declaration & discovery. We should define a single way of
declaring constraints.

Best,
Dimitris


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


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
Received on Friday, 23 January 2015 11:19:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 January 2015 11:19:45 UTC