Add option to resolve ARK references, from Archive.org etc. simliar to DOI

[wujastyk]

Archive.org auto-assigns an Archival Resource Key (ARK) to every item in its collection. ARKs are used by other institutions too. They function pretty much in the same way as DOIs. The main resolver for ARKs is http://n2t.net. They are designed to be persistent URIs. Many people use the ordinary URL of items in Archive.org for reference, but these URLs are messy, often very long, and assigned randomly by individual uploaders on no uniform scheme.

At present, I enter an ark into the Eprint field, and an Eprinttype of "ark". E.g.,

@Book{kale-1928,
  author      = {M. R. Kale},
  title       = {Bāṇa's Kādambarī [Pūrvabhāga Complete]},
  location    = {Delhi etc.},
  publisher   = {Motilal Banarsidass},
  date        = {1928},
  edition     = {3},
  eprint      = {ark:/13960/t8cg89f76},
  eprinttype = {ark},
}

In my LaTeX style file, I have this Biblatex macro:

\DeclareFieldFormat{eprint:ark}{%
    \textsc{ark:}\space
    \ifhyperref  
    {\href{https://n2t.net/#1}{\nolinkurl{#1}}}
    {\nolinkurl{#1}}}

This produces satisfactory results in bibliographies.

But in JabRef, I would like to be able to click a link and be taken to http://n2t.net/ark/13960/t8cg89f76, just as I can with a DOI or URL.

Is there a secret way to achieve this? To get a link into the Linked Identifiers column? If not, might a feature be added to JabRef to make this possible? It could be something hard-wired just for ARKs, or it could be a rule-based system that interpreted eprint and eprinttype data according to a rule like \DeclareFieldFormat above.

[akwala]

I'd like to take this on. I've read the Contribution document. Will touch base shortly in your chat channel.

[akwala]

Drafting the spec for this enhancement... Please provide feedback and tips, useful info, etc. are also welcome. (I'm just beginning to look at the code.)

Implement a new ID Type, ARK, that is similar to DOI

• Add ARK to the "General" tab in the entry detail window with the same buttons/functionality as DOI – use http://n2t.net/ to resolve an ARK.

• Add ARK to the ID Type list (dropdown) in the "New entry" window and mimic the options/actions for DOI.

[wujastyk]

Yes, parallel treatment to DOI for lookup and resolution seems the right way, as far as I can see.

On Sun, 11 Oct 2020 at 18:48, aslam karachiwala notifications@github.com wrote:

Drafting the spec for this enhancement... Please provide feedback and tips, useful info, etc. are also welcome. (I'm just beginning to look at the code.) Implement a new ID Type, ARK, that is similar to DOI

-

Add ARK to the "General" tab in the entry detail window with the same buttons/functionality as DOI – use http://n2t.net/ to resolve an ARK. [image: Screenshot_20201011_200058_scaled] https://user-images.githubusercontent.com/1786/95694649-2b8b9280-0c01-11eb-9031-de84cbacb420.png

Add ARK to the ID Type list (dropdown) in the "New entry" window and mimic the options/actions for DOI. [image: Screenshot_20201011_200750] https://user-images.githubusercontent.com/1786/95694980-d05a9f80-0c02-11eb-9722-fa168c2be99a.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/JabRef/jabref/issues/6696#issuecomment-706798535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF2DBUUM3LHZ7F65Q3ROXDSKJG6HANCNFSM4O7JFALA .

[Siedlerchr]

Hi, ARK is not a fetcher as far as I see there no way to get bibtex from an ark link. I would just implement it in the entry editor view model/field for the eprint type. Similar to Arxiv maybe. I vaguely remember there is some handling for the eprint field

[koppor]

JabRef needs to construct the BibTeX. It needs to apply some heuristics. For the example, the BibTeX is only

@misc{key,
    eprint      = {ark:/13960/t8cg89f76},
  eprinttype = {ark},
}

There is a side issue: We support doi as field (doi = {10.1007/s00450-019-00407-8}), but eprint = {doi:10.1007/s00450-019-00407-8}, eprinttype = {doi} is the same.

@wujastyk I wonder why ark appears both in eprint and eprinttype. Isn't the prefix ark: enough?

[akwala]

There is a side issue: We support doi as field (doi = {10.1007/s00450-019-00407-8}), but eprint = {doi:10.1007/s00450-019-00407-8}, eprinttype = {doi} is the same.

By "issue" do you mean this shouldn't be the case?

I wondered whether the "ark:/" should be in the eprint field. Is there a convention or rule for what comprises an eprint value?

Presumably, the "ark:/" URI can be constructed from eprint {sans "ark:/') and eprinttype ("ark"). Seems to me how the URI is determined should be consistent across eprinttypes.

(I am new to BibTeX.)

[wujastyk]

I have never seen an ARK reference without the ark:/ prefix. So I have presumed that it is not to be split off. But I could be wrong.

There's a statement of the standard here:

• https://en.wikipedia.org/wiki/Archival_Resource_Key

that says the structure is:

[http://NMAH/]ark:/NAAN/Name[Qualifier] The NMAH, Name Mapping Authority Host, is the resolver (commonly http://n2t.net). But it does look to me as if the "ark:/" string and the NAAN are always present.

On Wed, 14 Oct 2020 at 03:26, Oliver Kopp notifications@github.com wrote:

JabRef needs to construct the BibTeX. It needs to apply some heuristics. For the example, the BibTeX is only

@misc{key, eprint = {ark:/13960/t8cg89f76}, eprinttype = {ark}, }

There is a side issue: We support doi as field (doi = {10.1007/s00450-019-00407-8}), but eprint = {doi:10.1007/s00450-019-00407-8}, eprinttype = {doi} is the same.

@wujastyk https://github.com/wujastyk I wonder why ark appears both in eprint and eprinttype. Isn't the prefix ark: enough?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JabRef/jabref/issues/6696#issuecomment-708279486, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF2DBWILRHKJ4E57TK6UPLSKVVFTANCNFSM4O7JFALA .

[wujastyk]

I understand now that ARK is not a system for fetching BibTeX data (like DOI).

But I still think it should not be impossible to do something less ambitious in JabRef in order to get an ARK link appearing and live in the Linked Identifiers column of the database display. (I.e., putting the resolver URL, http://n2t.net on the front of the data from the eprint field.)

I think entering ark references using eprint and eprinttype is fine from the user and BibTeX point of view. But if having an actual ark field would materially help with getting the data into the Linked Identifiers column, then that should be no problem either.

So, I would prefer for this issue to remain open for the sake of this more modest goal of getting a clickable link into the Linked Identifiers column.

[wujastyk]

[Feature suggestion]

JabRef 5.5--2021-12-28--8e92228 Linux 5.13.0-22-generic amd64 Java 16.0.2 JavaFX 17.0.1+1

+1

For constructing clickable ARK refs in the "linked files" column, as mentioned above.

These could be constructed out of the eprint and eprinttype fields thus:

If eprrinttype has value ark then the linked files column can have a link to http://n2t.net/<eprint value>.

This could become a small, more general subsystem. JabRef could have an option to define a rule for any such linkable external source. In an options menu one could specify "if eprinttype = X, put link X-prefix/<eprint value> into the linked files column. Just a thought.

In the back of my mind, I'm thinking of BibLaTeX macros like this that I use routinely (BibLaTeX manual, 4.11.2):

\DeclareFieldFormat{eprint:ark}{%
    \textsc{ark:}\space
    \ifhyperref  
    {\href{https://n2t.net/#1}{\nolinkurl{#1}}}
    {\nolinkurl{#1}}}

\DeclareFieldFormat{eprint:academia}{%
    Academia.edu\addcolon\space
    \ifhyperref
    {\href{http://www.academia.edu/#1}{\nolinkurl{#1}}}
    {\nolinkurl{#1}}}
\DeclareFieldAlias{eprint:academia.edu}{eprint:academia}

\DeclareFieldFormat{eprint:tbrc}{%
    \textsc{TBRC}\space
    \ifhyperref  
    {\href{https://www.tbrc.org/\#!rid=#1}{\nolinkurl{#1}}}
    {\nolinkurl{#1}}}

[wujastyk]

Could this be considered for v.6?

[ThiloteE]

Related issue: https://github.com/JabRef/jabref/issues/6627#issuecomment-1002815225