Re: Shapes vs Classes (in LDOM)

-----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 02:44:00 UTC