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

Re: Shapes vs Classes (in LDOM)

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Fri, 23 Jan 2015 15:47:15 -0800
Message-ID: <54C2DD83.7050003@kcoyle.net>
To: public-data-shapes-wg@w3.org
Yes, but I could have a graph with related graphs, none of which are 
defined by classes. How do I then target a specific graph?

kc

On 1/23/15 3:14 PM, Holger Knublauch wrote:
> 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
>>>
>>>
>>>
>>
>
>
>

-- 
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 23:47:46 UTC

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