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