Preventing a series from inheriting creator info (name access point) from the collection level

53 views
Skip to first unread message

Emily Lonie

unread,
Feb 6, 2018, 5:34:21 PM2/6/18
to AtoM Users
Is there a way to prevent a series description from inheriting creator information from a collection-level description? 

This is obviously a very useful feature when dealing with a fonds, but when you have a collection with a number of different creators, there will be some series which do not have items by some of the creators that were indicated in the collection-level description. 

Thanks!
Emily

Dan Gillean

unread,
Feb 6, 2018, 6:09:20 PM2/6/18
to ICA-AtoM Users
Hi Emily!

Good question. Right now the way it is set up is that inheritance is automatic at lower levels - unless you manually add a different creator name. So one option would be to add a different creator name on the items in question.... Or perhaps you could remove the creator at the collection level, and only add it to those series where it fully applies to all children?

There are definitely some use cases that this functionality doesn't fit. If we were to design the feature again, I think I would recommend making inheritance a feature you can turn on or off via an administrative setting. 

Sorry, I wish I had a more robust answer! I hope that you are able to find a workaound that will meet your needs. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/aa0e65d4-8675-4101-a358-3cb93ce32dd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Emily Lonie

unread,
Feb 6, 2018, 7:12:34 PM2/6/18
to ica-ato...@googlegroups.com
Thanks Dan - I was thinking that manually entering the creator info at the lower level was probably the work-around, but I didn't want to give myself extra work if there was a nifty fix. 

Thanks!
Emily

On Tue, Feb 6, 2018 at 3:08 PM, Dan Gillean <d...@artefactual.com> wrote:
Hi Emily!

Good question. Right now the way it is set up is that inheritance is automatic at lower levels - unless you manually add a different creator name. So one option would be to add a different creator name on the items in question.... Or perhaps you could remove the creator at the collection level, and only add it to those series where it fully applies to all children?

There are definitely some use cases that this functionality doesn't fit. If we were to design the feature again, I think I would recommend making inheritance a feature you can turn on or off via an administrative setting. 

Sorry, I wish I had a more robust answer! I hope that you are able to find a workaound that will meet your needs. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

On Tue, Feb 6, 2018 at 5:34 PM, Emily Lonie <emily...@gmail.com> wrote:
Is there a way to prevent a series description from inheriting creator information from a collection-level description? 

This is obviously a very useful feature when dealing with a fonds, but when you have a collection with a number of different creators, there will be some series which do not have items by some of the creators that were indicated in the collection-level description. 

Thanks!
Emily

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/cpz6znLNvO4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-users+unsubscribe@googlegroups.com.

To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Creighton Barrett

unread,
Feb 6, 2018, 8:28:48 PM2/6/18
to ica-ato...@googlegroups.com
Emily, I'm glad you posted this - I was thinking about asking a similar question!

We've been wondering about the "best practice" for when dates of creation notes should include actor names and when the actor name should be omitted. If we include the creator in the date note, then the admin history/biographical sketch appears in the lower-level descriptions even though it's not really necessary there (unless, I suppose, the creator is different than the creator linked to the top-level description). It also affects how the authority record displays linked descriptions.

But if we don't include the creator in the date note, the "Narrow your results by creator" facet loses its value. It also means that data exported at lower-levels (e.g., EAD or Dublin Core XML) does not include creator information. 

So - are AtoM users always including an Actor name in the dates of creation note? Or are you only including an Actor name in the dates of creation note when the creator is different than the creator linked to the top-level description?

It doesn't seem particularly onerous to add the name to each description, but the choice does seem to have fairly significant implications for display, usability, reusing metadata, etc. I would love to hear how others are approaching this!

Cheers,
Creighton



--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Dan Gillean

unread,
Feb 7, 2018, 11:18:33 AM2/7/18
to ICA-AtoM Users
Hi Creighton, 

There's another factor at play to consider here as well: performance. 

Beyond trying to find a way to implement ICA best practices in description (description at the highest relevant level; not repeating information unnecessarily at lower levels) via the user interface, a practical reason for doing so was to limit the amount of updates that need to be made to related records with every edit. This is critical in a web based application where some tasks are still performed synchronously via the browser. 

If you have an authority record linked to 10 top-level descriptions, and you need to edit its authorized form of name, you should have no problem doing this via the user interface. If that actor is linked to a thousand or ten thousand lower-level descriptions, and you try to edit it, you are likely going to run into timeout issues: AtoM has to try to update 10001 records in the one minute time frame before the web browser times out, aborting the request. If you have custom group permissions that need to be checked on editing, the likelihood of that request timing out is almost 100%. The same is true for repository inheritance. 

For this reason, AtoM 2.5 will actually have  a command-line task that can be run by a system administrator to remove unnecessary actor links at lower levels, where inheritance would have produced the same results. See: 
There are ways in which we could improve AtoM to make this less necessary, but all solutions involve significant development - overhauling the permissions module, adding more job scheduler support, replacing the ORM in AtoM with something faster, etc.

Another factor that could affect usability - the list of related descriptions that displays on the authority record view page. This list is very useful when linked only to top level descriptions - but if you are linking an authority record at every level in thousands of descriptions, then there will be thousands of descriptions listed in the sidebar/context menu widget for "Creator of" on the authority record page, making it less useful for browsing. 

Just something else to consider! 


Note as well that the temptation to link at all levels is probably higher when using the RAD template, where creator and creation dates appear in the same modal, versus the ISAD template, where they are separate elements. We wanted to make them use the same approach during development, but the ICA strongly objected, so though the events data model is used throughout AtoM, the interface obfuscates this on the ISAD template somewhat and in the database's events table, you end up with 2 partial events  - a creator without dates, and a creation event without a creator. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Creighton Barrett

unread,
Feb 8, 2018, 2:40:14 PM2/8/18
to ica-ato...@googlegroups.com
Hi Dan,

Thanks for clarifying this. I recall you mentioning once that the repository inheritance helped improve performance so it makes sense that it could be a problem with authority records. We haven't experienced that yet, but have experienced timeouts trying to delete subject headings linked to 1000+ descriptions. I am very happy to hear about this command line task coming in v2.5 and appreciate all the clever approaches to solving important problems. 

Makes me wonder if there is some way to configure ElasticSearch so the advanced search and "narrow your results by" facets include all descriptions that inherit the authorized form of name, not just those that are directly linked to the authority record. Is that even possible?

Thanks again for the insight!

Creighton

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Dan Gillean

unread,
Feb 8, 2018, 3:46:24 PM2/8/18
to ICA-AtoM Users
Hi Creighton, 

I think that would be possible, but I have no idea how much development would be required. 

There is a field in the ES index called inheritedCreators.authorizedFormOfName, which we have made use of to solve this recent ticket: 
  • #11788 - Inherited creator names will not return search results for matching lower-level records
To make it work in the facet, you would likely need to combine a check against the creators.authorizedFormOfName field (which is what I believe is currently being used for faceting) and the inheritedCreators field. I don't know if you can do that sort of combination with a facet in ES - but I'm sure that you could if AtoM used filters instead of facets. Note that a switch to filters over facets is also likely what would be required to implement this long-standing wish list ticket, to make the filters show more than 10 results: 
That starts looking like a major overhaul however. Again, there might be an easier way to do this, I'm just guessing based on what I know (which isn't much). I'd need input from our developers to say for sure - but either way it will likely require community support for us to implement such changes. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Creighton Barrett

unread,
Feb 8, 2018, 9:23:03 PM2/8/18
to ica-ato...@googlegroups.com
Thanks a lot, Dan! That is all very helpful. I know nothing about ElasticSearch except how long it takes us to index our database :)

But I will give this some further thought. 

Cheers,
Creighton

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
Reply all
Reply to author
Forward
0 new messages