[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=61969#comment-61969 ]
James Amsden commented on OSLCCORE-45:
--------------------------------------
The TC sees some value in specifying oslc:range for oslc:Property as a better choice that oslc:allowValues, oslc:allowedValue, oslc:valueType, oslc:representation.
However, we don’t want to over-constrain implementations. Adding oslc:range in the OSLC specifications makes it much harder to change.
There are many oslc:Properties whose oslc:range rdf:type is "likely to be <a type> but might not be".
Specifying oslc:range for these properties might be too restrictive.
On the other hand, many reflective tools need the type information for their purposes.
[ ] Possible solution:
- Weaken the description of range so that it is recommended types, not required types
- Create an inventory of core object properties that could have a type and propose one
- Send out an email with this information and get feedback whether this should be included in the spec or not.
- Requires a vote
[ ] oslc:range property description:
In the specification body: The object resource SHOULD be any of the specified oslc:range types, but no inferencing is intended if the actual target resource is or is not one of these types. This is very different semantics than rdfs:range which does have inferencing implications.
This may already be weak enough.
in the shape file: "For object properties, an allowed object resource type."
Change to: "For object properties, specifies what the object resource type is expected to be, but that is not necessarily the case."
or just: "For object properties, specifies what the object resource type is expected to be"
[ ] oslc:range property values for OSLC Core
Common Properties:
- contributor - foaf:Agent
- creator - foaf:Agent
- relation
- type - rdf:type
- member
- serviceProvider - ServiceProvider
- instanceShape - ResourceShape
- discussedBy - oslc:Discussion
- modifiedBy - foaf:Agent
Comment
- inReplyTo - oslc:Comment
Compact
- icon
- largePreview - oslc:Preview
- smallPreview - oslc:Preview
CreationFactory
- creation - ldp:Container
- resourceShape - oslc:ResourceShape
- resourceType - rdf:type
- usage
Dialog
- resourceShape - oslc:ResourceShape
- resourceType - rdf:type
- usage
Discussion
- comment - oslc:Comment
- discussionAbout
Error
- extendedError - oslc:ExtendedError
ExtendedError
- moreInfo
OAuthConfiguration
- oauthRequestTokenURI
- authorizationURI
- oauthAccessTokenURI
PrefixDefinition
- prefixBase
Preview
- document
Publisher
- icon
QueryCapability
- queryBase
- resourceShape - oslc:ResourceShape
- resourceType - rdf:type
- usage
ResourceShape
- describes
- property - oslc:Property
- allowedValues - oslc:AllowedValues
- allowedValue - unspecified oslc:valueType
- defaultvalue - specified oslc:valueType
- occurs - oslc:Cardinality
- propertyDefinition - rdf:Property
- range - rdf:type
- representation - oslc:Representation
- valueShape - oslc:ResourceShape
- valueType - oslc:ResourceValueType
Service
- domain
- creationFactory - oslc:CreationFactory
- queryCapability - oslc:QueryCapability
- selectionDialog - oslc:Dialog
- creationDialog - oslc:Dialog
- usage
ServiceProvider
- publisher - oslc:Publisher
- service - oslc:Service
- details
- prefixDefinition - oslc:PrefixDefinition
- oauthConfiguration - oslc:OAuthConfiguration
ServiceProviderCatalog
- domain
- publisher - oslc:Publisher
- serviceProvider - oslc:ServiceProvider
- serviceProviderCatalog - oslc:ServiceProviderCatalog
- oauthConfiguration - oslc:OAuthConfiguration
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]