Uploaded image for project: 'OASIS OSLC Lifecycle Integration Core (OSLC Core) TC'
  1. OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
  2. OSLCCORE-45

Use of oslc:range, especially for enumerations, is unclear

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: None
    • Labels:
      None
    • Proposal:
      Hide

      Add Section "Defining Enumerations" to core-vocab.html.

      Update the Shape Resources Overview section to start with:

      "A resource shape is a resource that describes the contents of, and constraints on, the RDF representation of other resources. These constraints are intended to be applicable to OSLC core and domain vocabularies in order to express the domains sufficiently to support interoperability between clients and servers that use and support them. Resource shapes specify the minimum an implementation needs to do be considered compliant. Specifically:

      • All compliant implementations MUST do what the spec says when they get data that conforms to the shape.
      • Compliant implementations MAY also do something sensible when they get other data.

      That is, the intention is not that an OSLC implementation would reject a message if it violated shape constraints, rather the intention is that implementations do what is specified by an OSLC spec when they get data that conforms to the shapes."

      Add the following clause at the end of section 6.2 Associating and Applying Shapes:

      "If a resource satisfies its applicable shapes, client and server implementations MUST behave as described in the defining OSLC specifications. If a resource does not satisfy its applicable shapes, implementations SHOULD attempt to complete the operation with the given data if possible. Otherwise implementations MAY reject the operation."

      Specify oslc:range for most oslc:Property constraints in the core shapes.

      This would specify the "likely" type of the property, but would not prevent servers from using other types.

      Show
      Add Section "Defining Enumerations" to core-vocab.html. Update the Shape Resources Overview section to start with: "A resource shape is a resource that describes the contents of, and constraints on, the RDF representation of other resources. These constraints are intended to be applicable to OSLC core and domain vocabularies in order to express the domains sufficiently to support interoperability between clients and servers that use and support them. Resource shapes specify the minimum an implementation needs to do be considered compliant. Specifically: All compliant implementations MUST do what the spec says when they get data that conforms to the shape. Compliant implementations MAY also do something sensible when they get other data. That is, the intention is not that an OSLC implementation would reject a message if it violated shape constraints, rather the intention is that implementations do what is specified by an OSLC spec when they get data that conforms to the shapes." Add the following clause at the end of section 6.2 Associating and Applying Shapes: "If a resource satisfies its applicable shapes, client and server implementations MUST behave as described in the defining OSLC specifications. If a resource does not satisfy its applicable shapes, implementations SHOULD attempt to complete the operation with the given data if possible. Otherwise implementations MAY reject the operation." Specify oslc:range for most oslc:Property constraints in the core shapes. This would specify the "likely" type of the property, but would not prevent servers from using other types.
    • Resolution:
      Hide

      For oslc;Property shape for oslc:range, change the dcterms:description from "For object properties, an allowed object resource type." to: "For object properties, specifies what the target resource type is expected to be, but that is not necessarily the case."

      Ensure that the description of the property in the specification is consistent with this shape description.

      Show
      For oslc;Property shape for oslc:range, change the dcterms:description from "For object properties, an allowed object resource type." to: "For object properties, specifies what the target resource type is expected to be, but that is not necessarily the case." Ensure that the description of the property in the specification is consistent with this shape description.

      Description

      The Core 2.0 spec seems unclear about the intended usage of oslc:range, especially in relation to enumerated attribute types.

      http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#oslc_ResourceShape_Resource says:

      "For properties with a resource value-type, Providers MAY also specify the range of possible resource types allowed, each specified by URI. The default range is http://open-services.net/ns/core#Any."

      Whereas http://www.w3.org/Submission/2014/SUBM-shapes-20140211/ says:

      "oslc:range MUST NOT be used with datatype properties. It MAY be used with object properties. For object properties, oslc:range is used to specify an allowed rdf:type of the object resource. The value of this property MAY be any rdf:type URI or the following individual:

      oslc:Any
      This value specifies that there is no constraint on the type of the object resource."

      The latter seems to be more definitive, but fails to provide guidance about enumerations. Here is an example. Say there is an attribute representing Colour. It is an enumeration with the following members:
      label="red" uri=<http://example.com/colour/red>
      label="green" uri=<http://example.com/colour/green>
      label="blue" uri=<http://example.com/colour/blue>

      So in the property definition for this Colour attribute, one would say it has an oslc:valueType of oslc:Resource, and it has oslc:allowedValues of <http://example.com/colour/red>, <http://example.com/colour/green>, and <http://example.com/colour/blue>.

      The first description of oslc:range doesn't give guidance as to what URI should be referenced. It implies it's the URI of something that might define the range of values.

      The second description of oslc:range says it should be an rdf:Type URI. Well, what if in the colour example, we say that colours are defined with some RDF type URI. How does an OSLC client determine the labels of each allowed value (expressed as a URI)?

      Whereas if the intent is that a client should be able to do a GET on the oslc:range object resource, then the spec needs to say that.

      The usability of the spec would be greatly improved with an example of how to represent enumerated properties, and exactly what oslc:range object resources are supposed to be.

        Attachments

          Activity

            People

            • Assignee:
              ndjc Nick Crossley
              Reporter:
              DavidHoney David Honey
            • Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: