[Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI?

[Custer, Mark]

Celia,

I wish that this could’ve been accomplished with the initial release of the PUI, but there were a number of issues that didn’t allow that to happen (and I’m not sure of all of the technical issues, to be quite honest).

However, at Yale, we will be setting up re-directs from our current system, which uses the data that we include in ASpace’s EAD ID field as part of the permanent link, to the ArchivesSpace PUI.  For example, we’re using a simple table that maps our EAD IDs to our ArchivesSpace Resource database IDs.  So, I would still recommend pursuing that option since you can only update the links on your own website, and not links elsewhere, user’s bookmarks, etc.

But I agree with Cory and you that this should, ideally, use a value that’s not an ArchivesSpace value (like a database ID), but instead a value that will live on after ArchivesSpace.  That’s what Cool URIs are all about, after all: https://www.w3.org/TR/cooluris/

My preference would be to use what’s currently labelled the EAD ID field in ASpace, in combination with the Repository short name.  The reason:  the EAD ID (or recordid in EAD3) is a requirement in the EAD schemas (although, yes, it can be empty in those schemas, technically 😊).  And fortunately ArchivesSpace already ensures that those values are unique in the database.  However, ArchivesSpace does not require that field.  ArchivesSpace does require the Identifier field, but that maps to a field in EAD (archdesc/did/unitid) which is *not* required in the EAD schemas.  I also would not favor using that field for a URI due to the weirdness of how that field is parsed into 4 fields total (id0 – id3) in ArchivesSpace.   All that said, one reason why I imagine that ArchivesSpace does not require the EAD ID field is that it wants to be flexible enough to allow users to use the Resource records for anything  -- even, say, a piece of papyri, which should not have an EAD ID.  But there’s no reason that ArchivesSpace couldn’t take a tip from EAD3 and just re-imagine that field as a Record ID field instead.  That way, you’ve got an identifier (the record ID) that pertains to the record, which you could use as part of the URI (as long as it was made mandatory in ASpace), as well as an identifier that pertains to the material being described (e.g. a call number).

All my best ,

Mark

p.s. I’m one of the 4 people (currently ) who have already voted for this ticket.  I’d vote again if I could, since I really do think that Cool URIs are important.



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Celia Caust-Ellenbogen
Sent: Saturday, 27 January, 2018 12:32 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Do you agree it's important to be able to customize URLs/create PURLs in the PUI?

Hi everyone,

As part of migrating to the ArchivesSpace public interface, we have to update a lot of links to old EAD finding aids. This has me thinking about the persistence of URLs and not only the trouble of updating old links but what will happen when (hopefully never!) we move out of ArchivesSpace. That the URLs in the public interface are arbitrary poses a problem. My sysadmin tells me that if we were able to customize some portion of the URL, it would be possible to create a URL redirect map. In the absence of that, she doesn't want to create a million (or, more precisely, about 4,000) individual redirects. If we could customize some portion of the URL, that would let us set up redirects from the old system, and it would also position us to anticipate being able to set up redirects going into a new system and therefore have somewhat persistent URLs.

That's my understanding, at least. I don't have a firm grasp of these issues so I might be making false assumptions.

I'm wondering if other folks have been thinking about this issue. How are you approaching the problem? Do you have a strategy for this? Can anyone with a better understanding of ASpace's code and/or development priorities speculate on the likelihood that the option to customize the URL for the public interface might be added to a future release?

AR-1558<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1558&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=BASqaraHnwFq1U7hS8HnMtHQKQFJLdh8eHiFVLznZqs&e=> seems the most relevant ticket, and it's pretty old (v.1.4.2). If other people agree this is important, would you please upvote it, and hopefully increase the chances it'll get on the development roadmap?

Thanks!
Celia

--
Celia Caust-Ellenbogen
Friends Historical Library of Swarthmore College<https://urldefense.proofpoint.com/v2/url?u=http-3A__swarthmore.edu_friends-2Dhistorical-2Dlibrary&d=DwMFaQ&c=cjytLXgP8ixuoHflwc-poQ&r=7Ez68qVcrmRD6nn1FqwoHBDEOxeRUCPm3xGvnFT0zjU&m=-TroesUwSJgDpj8nwiZaURNx7lT3loiWGu3LQcass9U&s=p00oDbiV7Q47LGIKqsh76wZP_Vo0i8JS-YLkabbk4kc&e=>
610-328-8496
ccauste1 at swarthmore.edu<mailto:ccauste1 at swarthmore.edu>
she/her/hers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180127/29748ab9/attachment.html>