- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 24 Jan 2015 09:14:29 +1000
- 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