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
