Permalink-like support for URLs referenced in record
|Reported by:||skaplun||Owned by:|
|Keywords:||permalink bibupload FFT external URL cool||Cc:||dnoyes@…|
It would be great to be able to consider records stored in Invenio as master resources of information.
If a record references an external URL, a weak link between the record in Invenio and the external resource is created. What if this resource is moved? The URL in the record must be updated! But what if some service has been built that assumed the URL initially provided by Invenio in the record would have stayed forever? The service would be broken.
To solve this issue, Invenio should be considered as master, to serve URLs, so that if the external URL changes, it would suffice to update an internal redirection table, and any external client, would transparently have the update.
This could be implemented in the following way:
- we invent a new subfield to 8564 tag, that should contain an ID that will be used to build the "permalink". This subfield should be repeatable. Its value must be unique WRT the record. Say $7
- everytime bibupload is seeing an 8564 tag with URL (or an FFT that will cause the 8564 tag to be automatically created), if it is missing the $7 subfield will automatically allocate it (this ID will be uniquely generated after properties of the URL)
- a new URL handler should be added that would handle URLs such as:
such handle should check for authorization to access <recid> and should then check within the record what <ID> resolves to and should redirect the user using via an HTTP 307 (Temporary Redirect) (see also <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>)
- format elements that were previously delegated to display links to the external URLs should instead provide the permalink.
- if the $7 is missing upon formatting of the record, the original URL should be provided as compatibility.
- if the external URL changes and an update to the record in Invenio is necessary, one have simply to update (e.g. via BibEdit) the $u field for the URL, without touching the $7.
- additionaly we might decide that any bibupload that append a URL, whose field is specifying an existing $7, will erase the old field and will become the new URL.
- if a URL is added without specifying a $7 it would automatically receive one from BibUpload. However if then it becomes clear that this URL should be the new reference for a resource that was previously already specified, the $7 of the old URL will be added to the new one (so the URL will be resolved by two permalinks, and that's why $7 should be repeatable).
At CERN this might be useful, for example, to implement a more robust integration with MediArchive. CDS would be the master reference for MediaArchive URLs, and if an URL on MediaArchive would change, only the record in CDS would need to be updated (any service using CDS as master won't be affected).