Re: Shapes vs Classes (in LDOM)

We have had already many attempts to resolve the classes vs shapes 
discussion, but did not reach a conclusion yet. My hope is that having a 
specific syntax with specific examples may help us make better progress. 
Of course we could later apply what we have learned to other languages too.

Also: any thread on this mailing list may only be of interest to a 
subset of the WG.

Holger


On 1/24/15, 5:16 AM, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I don't understand why this determination should be done in the context of
> LDOM.  In my view either the working group should make the determination in
> a neutral setting or defer the determination until it has settled on a
> particular technology.
>
> That doesn't mean that LDOM should not include a proposal on how to make the
> determination.  However that would be specific to LDOM, and I don't see why
> the working group as a whole should be involved at this point.
>
> peter
>
>
> On 01/22/2015 07:57 PM, Holger Knublauch 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
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUwp4OAAoJECjN6+QThfjzcXAH/iTk2romI1s7KjjozNBxKjVa
> dwEPbJhWGT5zVNDtl2uWdLQInY9rISPJkdMvKrqulHp+gZwNgrRKQxKgKByAhMP3
> LlIUw2fT6a+KV8iPdWsh/x7DVQOK6fdDMy4kkp3P+LB7Sv0kZNlc/7HsxOJmbcfX
> 8wU/XRyczpIUK703O8OeHqoNUi7BGkcGhylfDE9KfgM4BeLjBJ7mCwVdUXqd1hF5
> 9gIO363reyacu1W53ZNIVPXJhDjHiLghnEy/5GypNIcVLPNkS0BA0UtTQeAwakMA
> +qzRFOWgAMk3JKeZdQXr041PHHDhf5XQmUFFzpUo/RbswvZ2zM6WyqDt+m9VbOw=
> =4pFd
> -----END PGP SIGNATURE-----

Received on Friday, 23 January 2015 23:19:05 UTC