ripping classes out of requirements in 2.5

In ShapeRequirements, I've reworked the definitions in 2.5 in terms of
shapes. Below is a simplified diff of the differences. With Holger's
approval, I'll make these changes and then remove the shapes/classes
objections.


--- /Requirements	2015-02-06 01:48:09.509870891 -0500
+++ /ShapeRequirements	2015-02-06 01:48:09.517870891 -0500
@@ -4,7 +4,7 @@
 
 ==== Association of Class with Shape ====
 
-The language needs to include an easy-to-use vocabulary to state that a given property is associated with a class, e.g. to populate input forms with appropriate widgets but also constraint checking.
+There will be an property to connect a class to a shape, with the implication that every instance of that class must conform to that shape.
 
@@ -30,16 +30,16 @@
 
-==== Property Values belonging to Datatype ====
+==== Property Datatype ====
 
-The values of a property on instances of a class may be limited by their datatype, such as xsd:string or xsd:date.
+The values may be limited by their datatype, such as xsd:string or xsd:date.
 
 
-==== Property Values belonging to Type ====
+==== Property Type ====
 
@@ -49,7 +49,7 @@
 
 ==== Property's RDF Node Type (e.g. only IRIs are allowed) ====
 
-The values of a property on instances of a class may be limited by their RDF node type, e.g. IRI, BlankNode, Literal, or BlankNodeOrIRI (for completeness we may want to support all 7 combinations including Node as parent).
+The values of a property may be limited by their RDF node type, e.g. IRI, BlankNode, Literal, or BlankNodeOrIRI (for completeness we may want to support all 7 combinations including Node as parent).
 
@@ -63,7 +63,7 @@
 
 ==== Property Default Value ====
 
-It should be possible to provide a default value for a given property, e.g. so that input forms can be pre-populated and to insert a required property that is missing in a web service call. This requirement is not about using default values as "inferred" triples at run-time.
+It should be possible to provide a default value for a given property, e.g. so that input forms can be pre-populated and to insert a required property that is missing in a web service call.
 
@@ -76,9 +76,9 @@
 
-==== Property Labels at Class ====
+==== Property Labels ====
 
-It should be possible to provide human-readable labels of a property in the context of a class, not just globally for the rdf:Property. Multiple languages should be supported.
+It should be possible to provide human-readable labels of a property in a shape, not just globally for the rdf:Property. Multiple languages should be supported.
 
@@ -90,9 +90,9 @@
 
-==== Property Comment at Class ====
+==== Property Comment ====
 
-It should be possible to provide human-readable descriptions of the role of a property in the context of a class, not just globally using triples that have the rdf:Property as subject. Multiple languages should be supported.
+It should be possible to provide human-readable descriptions of the role of a property in a shape, not just globally using triples that have the rdf:Property as subject. Multiple languages should be supported.
 
@@ -119,7 +119,7 @@
 
 ==== Property Value Enumerations ====
 
-It is a common requirement to narrow down the value space of a property by an exhaustive enumeration of the valid values (both literals or other).
+Shapes will provide exhaustive enumerations of the valid values (both literals or other).
 
@@ -132,7 +132,7 @@
 
 ==== Properties Used in Inverse Direction ====
 
-In many cases properties are used bi-directionally and then accessed in the inverse direction, e.g. parent = ^child. There should be a way to state value type, cardinality etc of those inverse relations without having to utilize a new property URI.
+Shapes will provide a syntax to require arcs into a node.
 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 6 February 2015 06:56:08 UTC