- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 23 Jan 2015 15:47:15 -0800
- 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