Re: Shapes vs Classes (in LDOM)

How would this work for vocabularies, like DC Terms, in which most 
properties have no domain declaration? One CAN provide class definitions 
in instance data, but AFAIK the use of classes in RDFS is optional. 
Should the validation standard be dependent on optional characteristics 
of the base language?

kc

On 1/22/15 7: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
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 23 January 2015 19:42:22 UTC