- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 24 Jan 2015 10:51:19 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <54C2EC87.1090909@topquadrant.com>
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 >
Received on Saturday, 24 January 2015 00:51:52 UTC