Re: ripping classes out of requirements in 2.5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.

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


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

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

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

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

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


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




peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU1MLnAAoJECjN6+QThfjz4mEIAKUYtgfipVTlGHXJz3s8drIB
o1slvsIEaqD5eUFosWXWkxTNMVrfKrEL+/mPO0T3UNU7r8TjrFBc4qYP63t4jITE
2wgcIDoFgy8auZZDxe1EVJmRJe2d9Id5crRuf4UzOc7hNj89+cuBsEKZTNcZ9ekC
NVt4MOV0SVSRPTWdkmtZ177jtoDZsRVk6bw/e63+2KTFmViSSrd8UCRXj3g8pfTH
yQs7FpwU0VxxVE6LZrxnrY589YwqQ+tArAdfP1a+IQRoLedA0csdWpwbhQdT1faz
tG+MiduIZ9YvX/hCHDXQHTFMchXnomtvA4tawfEH8mFhDzO9hoGbNi7q4RhWkRI=
=Dh78
-----END PGP SIGNATURE-----

Received on Friday, 6 February 2015 13:35:02 UTC