[OASIS Issue Tracker] (OSLCCORE-45) Use of oslc:range, especially for enumerations, is unclear

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61767#comment-61767 ] 

James Amsden commented on OSLCCORE-45:
--------------------------------------

On 05Feb I sent the following note to Arthur Ryman:

I'd like your advice on the usage of oslc:Property constraint oslc:range. I noticed it is rarely used in the OSLC Core or domain shapes, instead leaving the Range field in the table Unspecified and adding the likely rdf:type in the comment. This is used for example on common core properties like dcterms:createdBy and properties that cross OSLC domain specifications such as RM validatedBy and QM validatesRequirement. 

My understanding from Nick is that oslc:range may have been left unspecified in the OSLC 2.0 core and domain specifications because of the evolution of the shapes specification. It may also have been avoided in order to not over-constrain server implementations and to provide flexibility in links across domains.

However, many IBM OSLC tools use oslc:range as valuable metadata for various purposes, including query and report building, and to support more reflective interfaces.

The Core TC has been exploring the possibility of adding oslc:range properties to the shapes in order to provide this useful information. The question of over-constraining implementations came up, and perhaps uncovered a more fundamental question about the meaning of applicable shapes.

The shapes specification says that resources SHOULD satisfy constraints defined by applicable shapes. It doesn't say they MUST satisfy the constraints, or what it means if they don't satisfy the constraints, or in what context constraint evaluation would be assessed, reported and/or acted upon. I think this is intended to allow shapes to be used in very flexible ways and seems to be the right thing to do.

The question is, how do we interpret that regarding shapes in the OSLC specifications. For example, we'd like to use the highlighted clause to have oslc:range specify the "likely" rdf:type of the property, but allow other types to be used if the server desires. Is that consistent with your interpretation of the clause, or an abuse of shapes?

If it is consistent, then does it also apply to other properties such as oslc:readOnly? Is this a suggestion that the server should not allow writes, but it is free to do so if it meets some need?



> Use of oslc:range, especially for enumerations, is unclear
> ----------------------------------------------------------
>
>                 Key: OSLCCORE-45
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-45
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>            Assignee: Nick Crossley
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)