OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Nick Crossley commented on OSLCCORE-45:

I believe the right way to define enumerations in a vocabulary is to define a number of RDF individuals for the enumeration values, all of the same type. The type should be an RDF class defined in the same vocabulary.  Here is part of an example vocabulary I wrote for a notional OSLC Configuration specification for branch values:

# Branch enumeration

    a rdfs:Class ;
    rdfs:isDefinedBy oslc_config: ;
    rdfs:label "Branch" ;
    rdfs:comment "The class of possible branch values." .

    a oslc_config:Branch ;
    rdfs:isDefinedBy oslc_config: ;
    rdfs:label "trunk" ;
    rdfs:comment "Main development trunk." .

    a oslc_config:Branch ;
    rdfs:isDefinedBy oslc_config: ;
    rdfs:label "branch1" ;
    rdfs:comment "The first branch." .

    a oslc_config:Branch ;
    rdfs:isDefinedBy oslc_config: ;
    rdfs:label "branch2" ;
    rdfs:comment "The second branch." .

# Branch property used on configuration instances

   a rdf:Property ;
    rdfs:isDefinedBy oslc_config: ;
    rdfs:label "branch" ;
    rdfs:comment "Identifies a resource as one for a specific branch or variant of the component." .
    # Note that we DO NOT use rdfs:range oslc_config:Branch - we leave constraints to the shapes

And here is part of the configuration resource shape to accompany that:

   a                        oslc:ResourceShape ;
   oslc:describes           oslc:config:Configuration ;
   dcterms:title            "[Part of] the shape of a configuration." ;
   oslc:property            <#branch> .

   a                        oslc:Property ;
   oslc:name                "branch" ;
   oslc:occurs              oslc:Zero-or-one ;
   oslc:propertyDefinition  oslc_config:branch ;
   oslc:range               oslc_config:Branch ;
   oslc:readOnly            "false"^^xsd:boolean ;
   oslc:representation      oslc:Reference ;
   oslc:valueType           oslc:Resource ;
   dcterms:description      "A value distinguishing different variants of configurations of the same component."^^rdf:XMLLiteral ;
   oslc:allowedValue        oslc_config:trunk, oslc_config:branch1, oslc_config:branch2 .

It may be redundant to define both oslc:range and oslc_allowedValue in this case; leaving out the oslc:allowedValue and sticking to oslc:range means that the permitted values would always be the full enumeration set, not a possibly out of date subset. Of course, you might want to define a subset of the allowed enum values in some circumstances.

> 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: James Amsden
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]