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

Re: Shapes vs Classes (in LDOM)

From: Eric Prud'hommeaux <eric@w3.org>
Date: Sat, 24 Jan 2015 09:51:05 -0500
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Cc: Irene Polikoff <irene@topquadrant.com>, Jose Emilio Labra Gayo <jelabra@gmail.com>, Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Message-ID: <20150124145043.GC19369@w3.org>
* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2015-01-24 15:36+0200]
> I think this is getting off-topic and leaning towards constraint discovery.
> In the same way one can define different (ShExC/RS)shapes in different
> datasets one can also define different class constraints in different
> datasets.
> 
> I think Holger's point was about the constraint definition. As also Peter
> pointed out we have requirements for three types of constraints
> 1) Constraints on instances of a class
> 2) Global constraints and
> 3) Shape constraints in the way ShEXc & RS define them
> Holger's suggestion probably has good coverage for 1 & 2 but needs further
> input for 3.

(Assuming "Holger's suggestion" means the current LDOM text with shapes
 being classes.)

I see where you're going, but I don't see req 1 taking any advantage
of shapes being classes; fact the current model invites confusion. For
instance, if I have a contact like:

Schema:
  my:ContactShape {
      a (foaf:Person)?,
      foaf:mbox IRI,
      foaf:givenName xsd:string+
      foaf:familyName xsd:string
  }

, a use case for req 1 would involve a link from instance to shape:
Data:
    [ ldom:instanceShape my:ContactShape;
      a foaf:Person;
      foaf:mbox <mailto:kontokostas@informatik.uni-leipzig.de>;
      foaf:givenName "Dimitris" ;
      foaf:familyName "Kontokostas"
    ]

Saying that my:ContactShape is an rdfs:Class doesn't buy us anything.
More useful would be saying that it's an ldom:Shape because then one
can query for shapes, validate them (i.e. using the schema for schema)
etc.

The proposal that shapes have "a rdfs:Class" encourages readers to
guess that they should assign those constraints to foaf:Person (the
current examples also encourage this). This would of course lead to
conflicts with any other uses of foaf:Person.

I encourage Holger's experiment in separating shapes and classes with
some property.
<http://www.w3.org/mid/54C225AF.1050406@topquadrant.com>


> On Sat, Jan 24, 2015 at 1:09 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * Irene Polikoff <irene@topquadrant.com> [2015-01-24 00:31-0500]
> > > Why would this be a problem?  You can have one set of constraints for
> > one portal (constraint definition graph 1) and another set of constraints
> > for another portal (constraint definition graph 2). The fact that they both
> > say that they are constraints for the same class doesn’t seem to matter –
> > one application would use the first one and another application would use
> > the second one. There is no conflict. Further, if these were two
> > applications in the same enterprise, for example, there is also value in
> > capturing the fact that these are two different constraints for the same
> > class is valuable.
> >
> > What does it mean that one uses one set of constraints vs. another if both
> > sets of constraints are attached to the same class? For example, when would
> > I attach shape constraints to a foaf:Person, which is likely to be used in
> > many different places?
> >
> >
> > > From: Jose Emilio Labra Gayo [mailto:jelabra@gmail.com]
> > > Sent: Friday, January 23, 2015 11:48 PM
> > > To: Holger Knublauch
> > > Cc: RDF Data Shapes Working Group
> > > Subject: Re: Shapes vs Classes (in LDOM)
> > >
> > >
> > >
> > > On Fri, Jan 23, 2015 at 11:42 AM, Holger Knublauch <
> > holger@topquadrant.com> 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.
> > >
> > >
> > >
> > > I think that is a good step forward and I encourage LDOM to go more in
> > that direction. After taking a look a LDOM, I think one of the main
> > differences between it and ShEx is precisely the impossibility to separate
> > shapes (or sets of constraints) from classes.
> > >
> > >
> > >
> > > In my opinion, it is not practical when one is trying to describe the
> > contents of linked data portals and one is reusing concepts/properties from
> > different vocabularies.
> > >
> > >
> > >
> > > As a practical example, I would recommend the following paper [1] where
> > we used the concept qb:Observation in two different linked data portals.
> > The observations had different shapes in both portals with different
> > properties, but all the observations had the same type: qb:Observation. I
> > think that situation happens will happen a lot in real life linked data
> > portals.
> > >
> > >
> > >
> > > Yesterday, I proposed to add a user story inspired by that example.
> > >
> > >
> > >
> > > Best regards, Jose Labra
> > >
> > >
> > >
> > > [1] Validating and Describing Linked Data Portals using RDF Shape
> > Expressions, Jose Emilio Labra Gayo, Eric Prud'hommeaux, Harold Solbrig,
> > >
> > > 1st Workshop on Linked Data Quality, Sept. 2014, Leipzig, Germany
> > >
> > > PDF: http://labra.github.io/ShExcala/papers/ldq2014.pdf
> > >
> > > Slides: http://www.slideshare.net/jelabra/linked-dataquality-2014
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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> 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> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Saludos, Labra
> > >
> >
> > --
> > -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 Saturday, 24 January 2015 14:51:12 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 24 January 2015 14:51:13 UTC