...
Suggested openehr.org specs URL designation (which is very close to current scheme:
| http://openehr.org/releases/ | RELEASE[x.y.z]/COMPONENT[ | baseBASE, | rmRM, | amAM, | queryQUERY, | termTERM, | smSM, | cdsCDS, | its, confITS, CONF]/RELEASE[x.y.z]/spec_name |
|---|
For example: http://www.openehr.org/releases/RM/1.0.3/rm/ehr.htmlhtml (currently it is @ http://www.openehr.org/releases/RM/Release-1.0.3/ehr.htmlThis is a valid URL currently)
We also currently have other inconsistent URL schemes (for older releases) such as:
http://www.openehr.org/releases/1.0.1/architecture/rm/ehr_im.pdf
http://openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf
http://www.openehr.org/programs/specification/releases/1.0.2
NOTE: The only proposed changes to current scheme is I have also now included [itsITS]=Implementation Technology Specification and [confCONF]=Conformance as a COMPONENT of spec although it is a separate heading on our current specs page for convenience. I think the namespace "openehr-specs" is broader than what we assume on this page.
...
So taking the given example the corresponding identifiers.org URI will be:
| http://identifiers.org/openehr-specs/RM-1.0.3-rm-ehr | >>>automatic mapping>>> | http://www.openehr.org/releases/RM/1.0.3/rm/ehr.html |
|---|
NOTE: On openehr.orgside this can be an alias (probably automatic) and the actual location on web server can still be http://www.openehr.org/releases/RM/Release-1.0.3/ehr.html so the impact would be minimal but for simlicity's sake we may as well go with this URL scheme in future releases.
Another suggestion to consider is whether we want to provide alternate formats for our specs (e.g. html, pdf, open doc etc.). In that case we may want to redirect each spec to an autogenerated auto-generated placeholder page that would provide links to html, pdf etc. specs. This is commonly used for other specs on identifiers.org; see: http://co.mbine.org/standards/specification-infrastructure
...