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: Sat, 24 Jan 2015 09:14:29 +1000
Message-ID: <54C2D5D5.4030506@topquadrant.com>
To: public-data-shapes-wg@w3.org
If a property has no domain declaration, then it basically means that 
the domain is rdfs:Resource. Therefore you could define the constraints 
on the DC terms at the class rdfs:Resource and it should (by 
inheritance) apply to any instance that has an rdf:type triple.

To capture non-class-based constraints and cases without rdf:type 
triples, we have static/global constraints.

Holger



On 1/24/15, 5:41 AM, Karen Coyle wrote:
> 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
>>
>>
>>
>
Received on Friday, 23 January 2015 23:15:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 January 2015 23:15:10 UTC