Re: Shapes vs Classes (in LDOM)

Recursion could be expressed either via ldom:valueType or ldom:all. To make sure we talk about the same thing, could you send one example instance that fails and one that fulfills the constraints?

Holger


Sent from my iPad

> On Jan 24, 2015, at 12:43, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I expect that recursive shapes cannot be expressed in LDOM.
> 
> One example would be a version of Polentoni - those people who are from the
> north of Italy and whose friends are all Polentoni.
> 
> peter
> 
> 
>> On 01/23/2015 04:51 PM, Holger Knublauch wrote:
>> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUwwbPAAoJECjN6+QThfjzpVAIAKwPfE33iv8LHrTR5qffW6mc
> y7CdxCGQNsBUq24tQKA9XjqdT0b/UhMRvWRFb2TeaYkQEUPiG08q4DyaaJwzEXij
> XNaPBSIWg1tS4yPT9b3cOCmBHLUSbt8vyHHDS1Nx/KI9MzbqyxHzjQZ7wllIaSk7
> 7tx44NDjDnP3BmgI3UlbD77xPXBPaeuNMenb+6aMW9seANpzd1h5F0/X4tG6Pt1s
> 6Y3v+OKlkIbzozFCYQ7jlQksX0WqaXSdzKxVaUG2HTvSsvxgETSmkQOxB0QT6HaX
> 5iMG5DdamHcLrTH9aIO3b3iyAfKzEJFcoTJjdf23cHl14YBHg7jVyvsmPs+j5FE=
> =aNzh
> -----END PGP SIGNATURE-----

Received on Saturday, 24 January 2015 06:00:01 UTC