- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 23 Jan 2015 20:42:55 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <54C225AF.1050406@topquadrant.com>
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 Friday, 23 January 2015 10:43:29 UTC