W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Shapes vs Classes (in LDOM)

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

This archive was generated by hypermail 2.3.1 : Friday, 23 January 2015 09:44:48 UTC