- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 23 Jan 2015 04:57:35 -0500
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2015-01-23 11:43+0200] > On Fri, Jan 23, 2015 at 11:27 AM, Eric Prud'hommeaux <eric@w3.org> wrote: > > > * Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> > > [2015-01-23 11:03+0200] > > > 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. > > > We also decouple the schema declaration with the constraint declaration > > (*) > > > > > > # 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? > > > > If I understand you, you propose that § 2. Class Declarations be > > instead Shape Declarations. I believe this addresses the issues raised > > in the November Class vs. Shape wars: > > > > > > https://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/thread#msg37 > > > > https://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/thread#msg199 > > > > I believe the answer to the Can Shapes always be Classes thread > > > > https://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/thread#msg22 > > was "no", at least not for classes used elsewhere in the enterprise or > > public. > > > > My suggestion is to separate them for clarity. From my understanding a > class-based validation occurs when types are explicit in a node > while in shapes type is implicit in the sense that one would have to infer > the type of the node based on the shape characteristics. > In the end I see them as equivalent but it is easier and probably less > error-prone if we separate them. I think that shapes can be a subclass of classes, in that they describe a set of nodes (Peter's going to say "no, they describe the things identified by the nodes"). However, I think that there's an overwhelming need to have a distinction between a foaf:Person and the shape that describes a particular use a foaf:Person. > > — > > > > > > > (*) 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. > > > > This seems sort of like the difference between classes and interfaces > > in Java. (They're the same thing in C++, which is why C++ is so much > > more popular than Java.) > > > > > > > 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 > > > > -- > > -ericP > > > > office: +1.617.599.3509 > > mobile: +33.6.80.80.35.59 > > > > (eric@w3.org) > > Feel free to forward this message to any list for any purpose other than > > email address distribution. > > > > There are subtle nuances encoded in font variation and clever layout > > which can only be seen by printing this message on high-clay paper. > > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig > Research Group: http://aksw.org > Homepage:http://aksw.org/DimitrisKontokostas -- -ericP office: +1.617.599.3509 mobile: +33.6.80.80.35.59 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution. There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.
Received on Friday, 23 January 2015 09:57:40 UTC