- From: Jose Emilio Labra Gayo <jelabra@gmail.com>
- Date: Sat, 24 Jan 2015 06:53:58 +0100
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <CAJadXX+T+T9nAK00VD+SDUmHxE8VBToQ2+wP+DU=8QtLfswfKw@mail.gmail.com>
On Sat, Jan 24, 2015 at 1:51 AM, Holger Knublauch <holger@topquadrant.com>
wrote:
> One more thing:
>
> It would be very helpful to have specific examples of things that cannot
> be properly expressed with the current LDOM draft. I would like to ask
> those who support stand-alone Shapes to provide detailed shape declarations
> and corresponding instances that serve as grounding for this discussion.
>
> Many thanks,
> Holger
>
1.- It is not clear to me if you can represent inter-linked shapes? As an
example, you could define "Course" and "Student" where a Course shape
contains a property :student whose values must have the Shape Student, and
a Student could contain a property :course whose nodes have the shape of
Course. I think this is similar to Peter's example of recursive shapes.
2.- I noticed that you support "orConstraint" which is a step towards ShEx.
I wonder if you support cardinalities over different groups and
combinations of "orConstraints". The prototypical example is the Person
shape which can have: either a foaf:name or a combination of several
foaf:givenNames and one foaf:lastName.
3.- I noticed that you support ldom:minCount and ldom:maxCount, is it
possible to define unbounded repetitions like the regular expression
operators "+" and "*" ?
4.- Does it handle/distinguish open/closed shapes? Open Shapes means that
you can allow remaining triples, while closed shapes means that you are
only allowed to have the properties specified by the shape. For example,
with a shape like:
<Course> {
rdfs:label xsd:string
, :student @<Student>*
}
the nodes that have that shape contain one property rdfs:label with value
string and zero or more properties with shape <Student>. With open shapes
you could allow more properties that those, while with closed shapes you
could only allow those properties.
5.- I would definitely separate classes from shapes by default, following
the line of Dimitris examples. I am not opposed to have mechanisms to
associate them but I think they are two different concepts which don't need
to be related. When we are defining Shapes we are talking about the domain
of RDF graphs, describing the shape of those graphs (which arcs they have),
so we are at a lower level domain than when we are modeling classes.
Keeping them separate would allow both domains of discourse to be
interoperable and provide a much better separation of concerns.
Also, as I was trying to reflect in my proposed use case, Shapes can be
more oriented towards developers which don't need to understand semantic
web technologies. They only need to know how to generate/consume triples
with a given shape.
>
>
>
> On 1/23/15, 8:42 PM, Holger Knublauch 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.
>
> 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
Received on Saturday, 24 January 2015 05:54:46 UTC