Re: ripping classes out of requirements in 2.5

-----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-----

Received on Friday, 6 February 2015 14:53:20 UTC