Re: ripping classes out of requirements in 2.5

Oof, your mail formatting made mincemeat of the diffs. I think I've
reconstructed them.

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-06 05:34-0800]
> 
> 
> On 02/05/2015 10:56 PM, Eric Prud'hommeaux wrote:
> > 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.
> 
> I'm fine with this requiremment (modulo that I would prefer a different word
> than shape, but let's not get into this here). However, this is not the
> original meaning of this requirement, which was that there was some way of
> stating that a class can have values for a property.  That requirement,
> which was rather polarizing appears to be gone.

Hmm, I guess your interpretation is that the original requirement is
not satisfied by

  ex:Rectangle ldom:hasClassShape ex:RectangleShape .
  ex:RectangleShape ldom:property [ ldom:predicate ex:height ] .

but only by

  ex:Rectangle ldom:property [ ldom:predicate ex:height ] .

which appears to be a non-starter with the shapes croud.


> > @@ -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.
> 
> This change is not acceptable, as it does not state which values are being
> restricted.

This requires some wordsmithing that applies to most of the
requirements in the document. I think it's intuitively obvious that
we're talking about the objects of properties attached to whatever
node is being matched to a shape, but that's hard to specify without
marrying the validation use case.

I'm happy to specify everything in terms of validation, with a note at
the top that says "Shapes in this document are specified in terms of
validation. They can be used for other use cases such as interface
generation. In the validation context, this document that the process
will make a correspondence between property constraints in a shape and
the triples of a node being validated." If this is an acceptable
framework, I propose:

"The object of a corresponding triple may be constrained to be an RDF
Literal with a stated datatype, such as xsd:string or xsd:date."

If this is too formal, I propose:

The values of a property may be limited to be an RDF Literal with a
stated 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).
> 
> This change doesn't have the problems of the  previous one.

Is that someplace between a +0 and +1?


> > @@ -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.
> 
> The qualification may have been put in as an attempt to clarify the meaning
> of this requirement.  I don't think that the clarification is necessary, but
> some might.

Do you have some sense of what that clarification meant? Does it,
e.g. prohibit a processor from adding the default triples?


> > @@ -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.
> 
> The title should probably be something like "Property Labels in a Shape"

+1


> > @@ -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.
> 
> Ditto.

+1, "Property Comment in a Shape"


> > @@ -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).
> 
> s/will/can/

+1, seems to flow with the voice of the rest of the reqs.


> > @@ -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.
> 
> The original wording was too verbose, but this is not comprehensible.
> 
> How about
> 
> Shapes can use the inverse of a property in the same way that they use the
> property.

That sounds like we need to have a defined inverse property. I believe
the intent is that one be able to require arcs into a node. How about

"Shapes can have constraints where the tested node is the object of a
triple."


> peter
> 

-- 
-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 14:14:47 UTC