[Oslc-Automation] Actions 2.0 action on 8.2 (profile identifiers)

[John Arwe]

So let's play that out.
As a good Linked Data identifier, one hopes that when I "look it up" (GET 
on the URI) that "something useful" comes back.  Presumably, the spec 
section that defines it.  Suggests to me that we use the spec link to the 
heading as the identifier, and yes I'd use the {#my-value} wiki syntax to 
ensure that the fragment ID is stable even if the heading text changes. 
IIRC Ian suggested (perhaps seriously, perhaps off-hand) a vocabulary term 
(probably an individual).  These are not mutually exclusive by the way, as 
the example below demonstrates.
Using the spec heading as the link target suggests that the definition is 
anchored (tee hee) to a single version of a single spec... in this case to 
Actions *2.0*.  Thus, each time we rev the specs, we automatically get a 
new identifier.  That might be a bug or a feature, depending on your point 
of view -- by which I really mean, depending what exactly the identifier 
identifies.

Example: if Actions 2.0+1 comes along and defines "http request with 
resource shape", with exactly the same content as Actions 2.0, 
- is that a new thing? 
- Or is that something we'd just never do if the content (in particular, 
the normative requirements) were unchanged?
- what if 2.0+1 adds a new not-MUST-* (e.g. a Should/not) normative 
requirement ... is it still the same as in Actions 2.0?

If you think that "revving the document with unchanged content => new 
identifier" is a perverse result (and that it's a real case), you'd want 
to use a vocabulary term as the identifier because you have precise 
control over when new ones are minted.  If you think we'd never just copy 
in normatively unchanged content to a new document, it doesn't matter.
If you think that "adding a new Should => new identifier", especially if 
you think that must Always be true, either strategy would suffice.  The 
fact that its definition is not identical might suggest that 2.0+1 is a 
different thing; OTOH since clients would not care, maybe that difference 
takes the form of a new hunk of state (expressed only in prose) on the old 
resource, so one identifier suffices. 
Just like in conneg, you can have 1 URI for "the concept" (the resource, 
independent of the negotiated media type) and n URIs, one for each 
concrete representation (in a particular media type) of the same "concept" 
resource.  Or you can just expose the 1 URI (omit Content-Location from 
responses), whether or not the other n URIs exist or are directly 
retrievable.  Just like a W3C latest TR has several URIs... a "generic" 
one that identifies "the current latest draft of X", and also a more 
specific "this dated version of X".

Personally I find myself leaning toward a vocabulary term; the concept != 
any particular domain spec.


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140916/22e10567/attachment-0003.html>