Beta maṣāḥǝft supports some permalinks, and their use is documented in this page. The implementation is based on the consideration which can be found in Eckhart ARNOLD, Stefan MÜLLER Wie permanent sind Permalinks?, Informationspraxis Bd. 3, Nr. 1 (2017) https://doi.org/10.11588/ip.2016.2.33483.
The implementation of this functionality was carried out during and thanks to the fruitful exchange during the Workshop Digitale Editionen - Auffindbarkeit und Referenzierbarkeit in Hamburg 11-12 June 2019, organized by Timm Lehmberg for the Union der Deutschen Akademien der Wissenschaften and the Akademie der Wissenschaften in Hamburg.
The Beta maṣāḥǝft project guarantees the persistency of the urls starting with https://betamasaheft.eu for as long as possible while the persistent URLs in GitHub domains are guaranteed by GitHub.
The format of persistent URLs is
https://betamsaheft.eu/permanent/ [sha] / [rest of the url as in the website]The SHA is the same as in the commits in the GitHub repositories of the project organization, so that it should be possible to navigate between different permanent URLs of a same resource. However, the path to the file is not evident in the application, although it is the very same as in the GitHub repository, so each link is reproduced in full, for example
Version of 2018-10-22T09:54:12Z | SHA: 0f2ae90766f072a3e37c2da90ca9a9476314e096 committed to github by sologebre with the following message: additions |
---|---|
permalink to this version | https://betamasaheft.eu/permanent/0f2ae90766f072a3e37c2da90ca9a9476314e096/places/LOC1008Abarga/main |
source file at this version | https://raw.githubusercontent.com/BetaMasaheft/Places/0f2ae90766f072a3e37c2da90ca9a9476314e096/1001-2000/LOC1008Abarga.xml |
source file in github at this version | https://github.com/BetaMasaheft/Places/blob/0f2ae90766f072a3e37c2da90ca9a9476314e096//1001-2000/LOC1008Abarga.xml |
The persistence guarantee is limited to the underlying data as offered by the versioning in GitHub, that is to say that pointing at a given permanent URL the user will see the data he would have seen at that point, in the current context and in the current software visualization. All parts of the page loaded via external APIs or our current API will be at the latest state possible based on the selected version of the file in question.
Not all URLs of the website can be cited persistently with a permanent URL, only item views, selected parts of the DTS API, and selected parts of the IIIF API. A search or a listing is not referenceable in a persistent way. It is possible however to use anchors in a specific view of the html, to point to a specific part of that version. For parametrized URLs which are versioned in this way, also the parameters can be used as far as they are relevant to the latest specification for the given API (IIIF, DTS).
The fact that the permanent URL will point to that item but in the current context (not the context at that point) will determine changes in the content viewed in all parts which are related to the context, which are many. For example, a title of a manuscript may not appear in the same way, as it is produced by looking in the database at the records for the repository and the settlement of the repository as well.
On a simple item view, for any item, the button Permalink can be clicked to view all available versions of the file. For each of them three permalinks are offered.
- the one to the view of that version of the current file in Beta maṣāḥǝft
- the one to the view of that version of the current file in GitHub
- the one to the raw version of that file in GitHub
For example, looking at Epistle of Eusebius to Carpianus (generic record) and clicking Permalinks a series of table will be loaded from the GitHub API, which correspond to each commit in the repository relevant to that file. The history is complete in as far as the data is elaborated in GitHub since the first day of the project. Each version has the date and time of the commit, the sha identifying it, together with the message left by the committer.
This means that any committed version of every single file is citable.
This list is not to be confused with the Revisions of the data, which come instead
from change
elements in the TEI files and document the relevant
changes which the editors decided to record. These versions are all versions of the
file as committed to GitHub, so, all versions which at that point were displayed on
the application. Eventually it is possible to permanently refer to versions which
are never been visible to any one outside the project before, since the application
was opened to the public a bit later than the beginning of the project.
Selecting the first of the links, the one starting with https://betamasaheft.eu/permanent, for example https://betamasaheft.eu/permanent/1c598017ca8ef92f62adaa659c129c6ee3e9a137/works/LIT1349EpistlEusebius/main, you will be able to see the record at the point, that is the one I committed on 2017-05-12 at 11:46:02. You will find in this view only the content which was there, so, no text for example, and the Suggested Citation box , as well as the embedded metadata for citation which you can use to import, for example to Zotero, will also reflect the authorship at that point.
In the main items view this Suggested Citation box will contain a link to this page and the canonical URL of the item main view (not the permanent one to the most recent commit), because you might still wish to just cite the record and not a precise version. It is however wiser to switch to the most current version, which is the one in display, and cite the permanent URL from there, if you want to refer to this version exactly.
Note also the difference between the date of a given version and the date of access to the file. A reference to a specific version should contain two distinct dates, as the most recent version can be years old, or you could be seeing today an older version resolving one of the previous commits.
If you are citing passages via the DTS API, or looking at a IIIF manifest, you might
act similarly. While the latest state of the data is the one offered by the API, you
can look at what the current version of the API would have returned based on the
data at an exact version point. for example,
https://betamasaheft.eu/api/dts/collections?id=urn:dts:betmas:LIT1349EpistlEusebius
has now a citation structure, which it did not have at the given revision, at
https://betamasaheft.eu/permanent/1c598017ca8ef92f62adaa659c129c6ee3e9a137/api/dts/collections?id=urn:dts:betmas:LIT1349EpistlEusebius
Also the DTS API carries always evidence of all revisions of a file, to allow
navigation between them inside dc:hasVersion
.
This allows to use a citation structure which has been replaced by a newer one consistently (although it does not allow to find out correspondences between the older and the newer).