- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Fri, 23 Jan 2015 11:43:52 +0200
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a0E1WLA3RSPMDxKaTxF8Vm8q6LF3FX09oGzGaAFMO57yA@mail.gmail.com>
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. > — > > > > (*) 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
Received on Friday, 23 January 2015 09:44:47 UTC