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

[Martin P Pain]

For speed, I suggest we don't make them URIs, and avoid anything in the 
text that makes them look like URIs (i,e. avoid using them as anchor 
text).Any +1s/-1s/discussion on that?

Train of thought preceding that:

To me, the opening of that can of worms (John's email) suggests we should 
not make them URIs. My example image had not intended to make them URIs, 
although the fact that I had used them as links to other sections may 
certainly have made that confusing.

If we didn't make them URIs, implementation documentation may well still 
want to make the identifier a link to the description of that identifier - 
which would be a link to the spec section.

Another approach would be to ask the question "if these might not change 
between spec versions, why are they inside the spec, not 
separately-versioned documents". Although they would then need to state 
which version(s) of the interaction patterns they require... still a can 
of worms.

If we can't do it properly, let's not do it at all. (Although I'm still ok 
to give them string identifiers (cf dcterms:identifier)).


Martin


"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
16/09/2014 16:29:15:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net
> Date: 16/09/2014 16:30
> Subject: Re: [Oslc-Automation] Actions 2.0 action on 8.2 (profile 
identifiers)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> 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 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140916/f4700586/attachment-0003.html>