Re: ripping classes out of requirements in 2.5

In this thread, Peter and I discussed the wording for @@2.5

I proposed 8 changes, 7 of them seemed satisfactory to Peter.  Holger
updated the wiki reflecting 3 of them in
https://www.w3.org/2014/data-shapes/wiki/index.php?title=Requirements&action=historysubmit&diff=1260&oldid=1258
 and I have updated the remaining 4 in
https://www.w3.org/2014/data-shapes/wiki/index.php?title=Requirements&action=historysubmit&diff=1273&oldid=1266

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-02-06 06:52-0800]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> >>On 02/06/2015 06:14 AM, Eric Prud'hommeaux wrote:
> >>> 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.
> 
> Correct in all respects.  (It's not that I'm for this requirement either,
> but that's the way that I read it, and the new version is a different
> requirement.)
> 
> > 
> > 
> >>> @@ -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."
> 
> This last is what I was hoping for.
> 
> 
> >>> -==== 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?
> 
> Nope, just that the wording change doesn't have an effect on the requirement
> stated.
> 
> >>> @@ -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?
> 
> I'm not a proponent of this requirement.  Someone who is in favour of it
> should be figuring out whether the change is acceptable.
> 
> >>> @@ -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."
> 
> Probably OK.
> 
> >> peter
> >> 
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJU1NU1AAoJECjN6+QThfjzgCwH/ij07rXo7Fjx1g36A11fJUBA
> U+U4efW2PB3ybGnjM/B5pTfra4/b/BDJDx6tSxJsbyFq0YdHGXI5qRG1ZzYsHtDt
> FROy2s1b6Clc0wYxlLm8dP1qhdHQuq5WaYjHDqVTL/KUIZace1rjdkNXh/VQlPQP
> V9Yd7Jp7aEQGMRPls4bZsh8lXEVwYqxzuapyFy3/DU1d740fKsqBhdLLvpd/IW3X
> dEsLHO5j5PjxFZITgofaQ3nBwwbSv8lWy3eMFwAl64WtI7REnCReE/ZYvtfNPF90
> mdsJHAFUuhmKsIZe72IDP8xh4qjUE5JNeqWFymAGLZ/AY7r++3/UNEqOmxpuAJA=
> =r/Nr
> -----END PGP SIGNATURE-----

-- 
-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 Wednesday, 11 February 2015 11:42:41 UTC