Ballot Details: Mark oslc:LocalResouce archaic (CLOSED)
|Ballot Description||OSLC2 ResourceShapes describes oslc:valueType constraints on properties to allow domains to specify how object resource URIs should be represented in an RDF resource representation (or document). For object values, oslc:valueType has three possible values:
1. oslc:Resource - the representation is a URI reference to some external resource
2. oslc:LocalResource - the representation is a blank node in the containing document
3. oslc:AnyResource - the representation can be a blank node or URI reference
This property is related to the oslc:representation property which constrains how a resource is represented in an RDF document. This property only applies to object resources and has three possible values:
1. oslc:Inline - the resource must be contained inside the resource representation
2. oslc:Reference - the resource must be in a separate, external resource representation
3. oslc:Either - the resource can be inline or external
The combination of oslc:valueType and oslc:representation leads to some representations that do not make sense: LocalResource/Reference, LocalResource/Either, AnyResource/Reference.
In OSLC2, the notion of inlining a resource in a document, and the use of blank nodes to identify such resources were coupled. However, this is unnecessary. A resource that can be accessed separately by its own URI could still be included inline in the representation of some related resource. And resources that cannot be accessed separately could have fragment URIs relative to the document base. So it is unnecessary to couple blank nodes with inline representations, or for OSLC to specify any constraints on the URI representation within a document. Servers should be free to provide the inlined resource representations with either blank nodes or local URIs.
Proposal: The OSLC Core TC has already approved a motion to replace all instances of oslc:LocalResource with oslc:AnyResource to provide server flexibility in using blank nodes vs. local or global URIs for inlined resources. In order to enforce this best practice, the Core vocabulary property oslc:LocalResource should be marked as vs:term_status "archaic".
VOTING CLOSED: Monday, 29 February 2016 @ 2:00 pm EST
|Open Date||Monday, 22 February 2016 @ 2:00 pm EST|
|Close Date||Monday, 29 February 2016 @ 2:00 pm EST|
|Ballot Type||Official, as defined by organization policies and procedures|
|Number of votes cast (excluding abstentions)||7|
|Eligible members who have voted||7 of 8||87.5%|
|Eligible members who have not voted||1 of 8||12.5%|
|Options with highest number of votes are bold|
|Option||# Votes||% of Total|
|Voter Name||Company||Vote||Time (UTC)||Comments|
|Amsden, James||IBM||Yes||2016-02-22 19:25:00|
|Crossley, Nick||IBM||Yes||2016-02-23 14:15:00||1|
|El-khoury, Jad||Swedish Royal Institute of Technology||Yes||2016-02-24 20:24:00|
|Honey, David||IBM||Yes||2016-02-23 12:00:00||1|
|Johnson, Jean-Luc||Airbus Group SAS||Yes||2016-02-26 16:01:00|
|Krishnaswamy, Harish||Software AG, Inc.||Yes||2016-02-26 04:56:00|
|Sarabura, Martin||PTC||Yes||2016-02-22 20:06:00|
|Yes||I don't understand why we have both oslc:valueType and oslc:representation, as they are both trying to describe the same thing. So why are they using different enum URIs at all?
If having both does serve a purpose, then oslc:AnyResource should allow a referenced to be inline or reference, and exactly equivalent to oslc:Either. In other words it may be a reference to a URI either in the same graph or another graph to a blank node.
|Yes||The updated specification should have text to explain this change somewhere, perhaps along the lines:
"oslc:LocalResource constrains the representation to be a blank node. Such a constraint is seldom useful (for example, it does not allow a hash URI). Domains should avoid this value, and use a representation of oslc:AnyResource with a value type of oslc:Inline where appropriate."