If applying this to more metadata has been such a good idea for a
decade, why wasn't it adopted much more? Answer - we don't know.
This absence of certainty appears to have been a legitimate source of
concern for many people.

Likely because the information on the web was until now useful for humans but opaque to computers. As we're taking it to the next level with cloud, semweb, etc. our demands on the aging infrastructure are increasing and features such as the Link: header which were originally specified in HTTP back in 1997 are being revitalised.

Would it make you feel more comfortable if I were to tell you that Amazon have been using HTTP headers for arbitrary metadata for years? "In REST, user metadata keys must begin with "x-amz-meta-" to distinguish them as custom HTTP headers."

We are doing infrastructure, and basing it as much as possible on prior art.

We are doing infrastructure today but my proposed roadmap has provision for both platform and application layers tomorrow (which is why I went to great lengths to separate out OCCI Core after the fact). Sure we should take one step at a time but confining ourselves to infrastructure is not seeing the forest for the trees. Furthermore, the standard as it stands today can trivially cater for any kind of resource you throw at it because the data channel completely clean (there are no Atom or SOAP headers, XML, JSON or other formats that need parsing - everything you need is right there in your existing HTTP user agent).

It's taken me 6 months pretty much full time to crack this particular nut and I'd very much appreciate if you were to give this work the consideration it deserves. As for "prior art", were that the case we'd have just rubber stamped one of many existing infrastructure APIs (and in doing so delivered one vendor a huge competitive advantage over all the others).

Sam