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

Re: Shapes vs Classes (in LDOM)

From: Holger Knublauch <holger@topquadrant.com>
Date: Sun, 25 Jan 2015 10:53:45 +1000
Message-ID: <54C43E99.5030509@topquadrant.com>
To: Eric Prud'hommeaux <eric@w3.org>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
CC: Irene Polikoff <irene@topquadrant.com>, Jose Emilio Labra Gayo <jelabra@gmail.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>

On 1/25/15, 12:51 AM, Eric Prud'hommeaux wrote:
> * 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.

If rdfs:Class rdfs:subClassOf ldom:Shape then any class can be used 
whenever a shape is required. So classes will in fact be more expressive 
than shapes (they already have inheritance built in). To me the only 
remaining question is whether users would find it more "clean" or 
"intuitive" to have a special term "shape" for what is essentially the 
same thing as "class". We could mark those classes that are only used 
for validation with ldom:abstract or whatever if it helps.

> 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 same arguments go in the other direction. Why introduce another 
concept for something that already exists. You can query for classes, 
validate them etc. oslc:instanceShape is basically the same as rdf:type 
- an instruction for the engine to match the instance against a shape. 
It's a duplication that some people seem to find appropriate, while 
others disagree.

> 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>

I still plan to experiment with that - I definitely want to see all your 
use cases covered well.

Received on Sunday, 25 January 2015 00:54:19 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 25 January 2015 00:54:19 UTC