Should ARKs of information resources return the information resource or a landing page?

[Mario Xerxes Castelán Castro «Ksenia»]

There is the following choice on implementing resolution for persistent
identifiers that identify a self-contained file (PDF, image, etc.): What
should exactly the persistent identifier resolve to? The distinction
between a resource and a landing page of the resource is important for
the semantic web. Let us take the example
<https://example.org/ark:12345/2pr23>. Choices are:

* <https://example.org/ark:12345/2pr23> is a landing web page. The
persistent identifier for the actual resource is
<https://example.org/ark:12345/2pr23?raw>

* <https://example.org/ark:12345/2pr23> redirects to
<https://example.org/ark:12345/2pr23?landing> which is a landing page.
The persistent identifier for the resource is as above.

* <https://example.org/ark:12345/2pr23> is the actual resource. The
resource and HTTP response contain in its metadata and in prose (if
possible) a link to <https://example.org/ark:12345/2pr23?landing> which
is a landing page.

* Allocate different persistent identifiers to the landing page and the
resource itself. E.g.: The resource itself is
<https://example.org/ark:12345/wrm31> and the landing page is
<https://example.org/ark:12345/2pr23>.

What are the reasons for why one would chose one instead of the other?
Related comments are encouraged.

There is a possible problem when designating a scheme for inflections in
that using words in English would be out of place or be interpreted in a
different, unintended way, when persistent IRIs are embedded in a text
in a language other than English. Perhaps inflections should be opaque
too. I.e.: instead of “?landing”, use “?469c3”. However this defeats the
purpose that inflections are self-explanatory.

[Roxana Maurer-Popistașu]

Hi Mario,

That's an interesting discussion to be had. Some of these points at least are being discussed currently in the AITO Technical Working Group as part of the discussion to change the inflections.

At the National Library of Luxembourg the ARK points to the resource itself (always in its current version). That's what we thought at the time of implementation that the end user might prefer. We might change that once the new ARK specification is finished and something else is recommended.

Your post made me think of an article I recently read: Persistent identifiers for heritage objects by Lukas Koster, from the University of Amsterdam. He also has some thoughts and recommendations about these issues. What do you think of his point of view?

Kind regards,

Roxana Maurer

[bertran...@bnf.fr]

Hi Mario, hi everyone,

 

Until now, this was a decision up to the implementer, though John raised several times this question (e.g., in Kunze, J., Calvert, S., DeBarry, J.D., Hanlon, M., Janée, G. and Sweat, S., 2017. Persistence Statements: Describing Digital Stickiness. Data Science Journal, 16, p.39. DOI: http://doi.org/10.5334/dsj-2017-039, section "Common content reference points" or during the ARK experts day at the Naional French library in March 2018). As Roxana said, the AITO working groups are currently looking for a convention, probably using the inflexion mechanism, to request in a standard way either the information object or a landing page with all provided services and context metadata.

 

I also wanted to mention other communities' answers to this question:

- Europeana uses two different properties: edm:isShownBy ("the main representation of the record") and edm:isShownAt ("the web view of the record in full information context, on the original institution's website") that provide two ways of reaching a digital representation of a cultural heritage object.

- WPUB (a standard elaborated by W3C for web publications) decided that a WPUB URL should resolve to an HTML toc with links to structured metadata and the JSON manifest (https://github.com/w3c/wpub/issues/94).

 

I hope that helps a little!

 

Kind regards,

Bertrand Caron
Département des Métadonnées
Bibliothèque nationale de France
Quai François Mauriac
75706 Paris Cedex 13
01 53 79 42 23
bertran...@bnf.fr

 

 

----- Message d'origine -----
De : "Roxana Maurer-Popistașu" <roxana.p...@gmail.com>
Envoyé par : arks-...@googlegroups.com
A : "ARKs" <arks-...@googlegroups.com>
Cc :
Objet : [arks] Re: Should ARKs of information resources return the information resource or a landing page?
Date : mar. 21 avr. 2020 08:41

--
You received this message because you are subscribed to the Google Groups "ARKs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arks-forum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/dc636bbd-28e8-485b-8c3a-e67006e43261%40googlegroups.com.

 

---

En raison de la situation sanitaire en France concernant le Covid-19, et suite aux instructions du Gouvernement, tous les sites de la Bibliothèque nationale de France sont fermés au public jusqu’à nouvel ordre.

Avant d'imprimer, pensez à l'environnement.

[Mario Xerxes Castelán Castro «Ksenia»]

El 21/04/20 a las 1:42, Roxana Maurer-Popistașu escribió:

> At the National Library of Luxembourg the ARK points to the resource
> itself (always in its current version). That's what we thought at the
> time of implementation that the end user might prefer. We might change
> that once the new ARK specification is finished and something else is
> recommended.

Thanks for the info.

> Your post made me think of an article I recently read: /Persistent
> identifiers for heritage objects/
> <https://journal.code4lib.org/articles/14978> by Lukas Koster, from the

> University of Amsterdam. He also has some thoughts and recommendations
> about these issues. What do you think of his point of view?

I mostly agree except for some details. In “Object types eligible for
PID’s” the article argues for a narrow policy of assigning PIDs to
abstract resources and only in exceptional circumstances to each of
their concrete instances. My opinion is when concrete instances are
long-lived (like an archived PDF file and unlike a dynamic web page),
one should assign a PID to them because the cost is negligible and the
benefit is potentially significant: To be able to persistently link to
the instance and talk about it in the semantic web with more ease.

In several places it argues in favor of content negotiation to
facilitate RDF. I argue that content negotiation is undesirable for a
resource that has a PID because it makes unclear what the PID exactly
refers to. Better use another way to link the RDF to the resource (see
below).

There are some mistakes:

Mistake 1: “In order to be used as a Linked Data identifier in RDF a URI
has to comply with a second condition besides resolvability: content
negotiation”. There are methods to associate a resource with linked data
without content negotiation:

* RDF can be embedded in the content itself. E.g.: Embed RDF in an
(X)HTML web page using RDFa or an element like “<script
type="application/ld+json>[...]</script>” with the RDF data serialized
in JSON-LD.

* Use HTTP headers or “link” (X)HTML element to point to the URI that
contains the RDF data. Details are in
<https://www.w3.org/TR/powder-dr/#assoc-linking>

Mistake 2: “URI’s exist in two forms: URN (Uniform Resource Name) and
URL (Uniform Resource Locator).”. URN is a single scheme of URIs defined
in <https://tools.ietf.org/html/rfc8141>. The term “URL” is an obsolete
name for what is now know as URIs. The term “URL” is not used in W3C nor
IETF standards since ~20 years ago. The HTML5 standard by the WHATWG
(which is notable for disregarding pre-existing standards) uses “URL” as
a synonym of “URI”.

[Mario Xerxes Castelán Castro «Ksenia»]

Related to the previous message, Berners-Lee wrote about the issue of
generic resources and a OWL vocabulary to link generic resources to
their concrete instances: https://www.w3.org/DesignIssues/Generic.html

Note that it does not answer the original question, the one in the topic
of the thread.