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

[Celia Caust-Ellenbogen]

Hello again,

Christine commented on the original ticket that to move forward there needs
to be a specification for how this would function. If anyone wants to work
on this with me, let me know!

Celia

On Sat, Jan 27, 2018 at 3:11 PM, Custer, Mark  wrote:

> 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-boun...@lyralists.lyrasis.org [mailto:
> archivesspace_users_group-boun...@lyralists.lyrasis.org] *On Behalf Of *Celia
> Caust-Ellenbogen
> *Sent:* Saturday, 27 January, 2018 12:32 PM
> *To:* Archivesspace Users Group  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
> pu

Re: [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-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Celia Caust-Ellenbogen
Sent: Saturday, 27 January, 2018 12:32 PM
To: Archivesspace Users Group 
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__swarthmo

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

[Celia Caust-Ellenbogen]

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  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

610-328-8496
ccaus...@swarthmore.edu
she/her/hers
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group