[Archivesspace_Users_Group] Discontinuing use of "levels of description" labels?

[Cory Nimer]

Jordon,


Another case similar to Steve's Aeon example is that the level value can be used in establishing inheritance rules for element display. If you are using the PUI, you can limit the inheritance of specific elements to prevent them from being included in archival object displays based on their level of description value. An example of this is provided at the end of the record inheritance section of the configuration documentation (http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/?).


Best,


Cory Nimer

University Archivist

Brigham Young University

801-422-6091


________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu>
Sent: Friday, March 8, 2019 12:51 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Discontinuing use of "levels of description" labels?

In EAD, the hierarchy is fixed, but one of the advantages of linked data is that the elements are movable and reusable in other contexts. We're not really taking advantage of that currently in ArchivesSpace, but for the future I think it makes sense to think about those use cases and whether level-of-description might be useful if the archival object is removed from its context.  ( For example, organizing artificial or virtual collections from subsets or multiple archival collections for exhibits or other display purposes - whether that's done in ArchivesSpace or by another tool importing info from ArchivesSpace. )

I will also note that we are currently integrating Aeon with ArchivesSpace - currently in testing and not yet in production here, so we don't have a lot of experience yet, but I think it may be useful to have level-of-description included in those requests (another instance where you are seeing the info removed from it's context) and we are considering filtering request so that only the lowest level items are units that can be requested ( although this can be perhaps better implemented just by looking at whether the item has children. )


- Steve.


On Mar 8, 2019, at 2:29 PM, Jordon Steele <jsteele at jhu.edu<mailto:jsteele at jhu.edu>> wrote:

Hi all,

This is more of an archival description question, but I'm not a member of that listserv, so I figured it would be easier to ping some of you about this for advice since I wager there's a lot of overlap.

We have not-infrequent discussions around here about what "level of description" label to assign to an archival component at a given level, i.e. collection, series, file, item, etc. But because our data is already structured in hierarchical relationships via EAD/JSON, there's no real need to "tell the computer" what level this is since these labels aren't the way computers understand context and hierarchy, the nesting of data is.

Once I realized this, I often made the case that these level-of-description labels are useful for stylesheets, i.e. tell a stylesheet with level=series to make it all caps and bold, level=file should be red, etc. But the ASpace PUI doesn't/doesn't need to style levels in this manner for the hierarchy to be easily understood.

So we're considering discontinuing use of the "level of description" field in ASpace. But am I missing an important value of this field? Thanks!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
jsteele at jhu.edu<mailto:jsteele at jhu.edu>
410-516-5493
he/him/his

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190310/8cdac296/attachment.html>