Purpose of ERC "where"

[Mark Jordan]

Hi everyone,

I'm looking for some clarity on the purpose of the ERC "where" property. Section 5.1.2 of the ARK spec says "A description must at a minimum answer the who, what, when, and where questions ('where' being the long-term identifier as opposed to a transient redirect target) concerning an expression of the object." Assuming the ARK that a description applies to is the "long-term identifier", does this mean that the value of "where" should be the ARK itself (unlikely since that would be a circular reference)?

I had up until now understood that "where" could contain the "transient redirect target", i.e., the current URL of the object. Using the current URL of the resource as the value of "where" is consistent with the no-type/anchoring Kernel story defined in section 3 of the DCMI Kernel spec but in typed stories "where" takes on other semantics. For our initial creation of ARKs for about 500k objects as part of a migration to a new repository platform, our ERC metadata will follow the no-type/anchoring Kernel pattern, so I am hoping that using the object' current URL as the value for "where" does not run too counter to section 5.1.2 of the ARK spec.

Please let me know if that question doesn't make any sense.

Mark

[John Kunze]

Sorry for the late reply. The purpose of the ERC is to be a ready-to-go basis for citation. That means the "where" property should contain the official ARK that one would use to get to the object/resource.

That may seem counter-intuitive, or perhaps redundant. After all, you just used that ARK to request the ERC, so why show it to you again? Similarly, why is it a best practice for articles to have their own identifiers printed on them ("to wear their own identifiers")?

The reason is that you may have been routed to this ERC metadata, or one of its copies, via many different paths. Out in the wild, objects or blocks of metadata have an unfortunate tendency to get separated from their identifiers. So the ERC keeps reminding us of the persistable/persistent id because technologies (especially browsers that re-write PIDs to their current transient URLs) keep helping us to forget them. Of course, the transient redirect target that you were considering has an important backroom role in persistence, but not as part of the minimal ERC, whose elements are meant to be user-facing (despite the plain text packaging).

--
You received this message because you are subscribed to the Google Groups ARKs group. To post to this group, send email to arks-...@googlegroups.com. To unsubscribe from this group, send email to arks-forum+...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/arks-forum?hl=en
---
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/37885902919b4645bf68f938e43ea0f3%40sfu.ca.

[Mark Jordan]

Thanks John, that's clear and all makes sense. I think what threw me off is that a number of the ERC examples in https://www.dublincore.org/groups/kernel/spec/ don't contain what is recognizable as a PID, they contain what look more like resource target URLs.

Mark

---

From: arks-...@googlegroups.com <arks-...@googlegroups.com> on behalf of John Kunze <jak...@gmail.com>
Sent: Thursday, September 7, 2023 1:21 AM
To: arks-...@googlegroups.com
Subject: Re: [arks] Purpose of ERC "where"

 

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/CAOmcTKg5LXPbkOs%2B0f8aZuEkqZAG%2BmYqC8GkCOmK11WHPMOw6w%40mail.gmail.com.

[John Kunze]

Good to know where we should turn attention to improving the documentation.

To view this discussion on the web visit https://groups.google.com/d/msgid/arks-forum/1798e19414024ee8bb40cce206c471bf%40sfu.ca.