Re: Shapes vs Classes (in LDOM)

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.

Holger

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