Re: Shapes vs Classes (in LDOM)

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.

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