Editing Place Access Points and Links to Descriptions

[colle...@cumberlandmuseum.ca]

Hello!

I have found an odd occurrence when place access points are added from the "Event" pop up box in dates of creation. It shows up as a as a "place" access point record and says there are 0 related records.... however if you go to delete that record (if it is incorrect) it says that it is used in __ number of descriptions. The trouble with this is that it isn't then possible to find the descriptions that it is linked to and i cannot then go in and add the correct access point to them. 

Is there a way around this? I have attached a word doc with screencaps, hopefully that helps explain the issue. 

Essentially what i am wanting to do is delete the incorrect and duplicated place access point then go to the records it has been used in and add the correct access point. 

Thanks so much!!

-Melissa

[Dan Gillean]

Hi Melissa, 

That is an interesting one! 

I could likely talk to our team and help craft a SQL query that will identify the related descriptions, but I might have an easier solution for you. 

You might consider using the taxonomy normalization task. This task will take terms in the target taxonomy that are exact duplicates of each other, and it will move the description relations from the duplicate (i.e. the newer) term to the original (older) term, before deleting the duplicate. See: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-tools/#taxonomy-normalization  
  

So: if both terms are entered EXACTLY as Montreal (Q.C.) for example then this task should meet your needs. If they are not currently exactly the same, then you can just edit one to match the other via the user interface. 

A couple caveats for consideration: 

1) This is a command-line task, and therefore requires CLI access to run. As a hosted client with Artefactual, please feel free to email our support address if you'd like to follow up on this. 

2) Note that other relations are NOT passed during the move. So if the new term was part of a term hierarchy (such as North America > Canada > Quebec > Montreal (Q.C) or something, and the old term was not, the old term will not be given this place in the term hierarchy. The same is true of related terms - they are not passed by the task. 

3) Additionally, scope and source notes are not moved. So if your old term was mostly blank, but the new duplicate one had a scope note, that scope note would be deleted when you ran the task. 

In light of these, I recommend that you review both terms, and make sure that a) the authorized form of name is identical for each, and b) that any other relations or notes are present on both terms (in case you don't know which is the original), so that nothing is lost. I also suggest you take a quick look at other terms in the taxonomy, to find out if there are other duplicates that will be impacted by running the task. 

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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/89b5a6da-a4d6-459c-8814-ff2dc8cc03ba%40googlegroups.com.

[li...@orangeleaf.com]

I have the exact same problem.

We have run the script as suggested by Dan but this hasn't fixed the problem although it has changed what happens

Our problem:

We have archival descriptions which have a place associated to it.

There are no Places associated to the record via placeAccessPoints rather the place name has been added to the eventPlace field for the associated event Creation

In the Places list we have two entries for eg Bath in the list, both showing no linked archival descriptions

When I click on the first one it says no related archival descriptions
When I click on the second one it says its been deleted but it still appears in the list (this is new since running the script, before that it would say there are x related description)

Any help greatly appreciated.

[Dan Gillean]

Hi Linda, 

This sounds like it could be a caching issue, or possibly some issue with the nested set. I'm going to suggest a few maintenance tasks to see if this helps resolve the issue. All the commands below should be AtoM's root installation directory - that is, /usr/share/nginx/atom if you have followed our recommended installation instructions. 

First, if you do want to try running the taxonomy normalization task to merge exact duplicates as I described for Melissa in my original post, do this first if you haven't already. 

Once that is done, let's start by rebuilding the nested set. More details on what this task does and how to run it can be found here: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#rebuilding-the-nested-set
  

Now, let's clear the application cache, and restart memcached and PHP-FPM (each of which also use caching to help speed up response times). To clear Symfony's cache: 

• php symfony cc
• See:  https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#clearing-the-application-cache

Now we'll restart PHP-FPM and memcached, if you are using it (it won't cause any issues if you try to run the command and it's not installed). 

To restart PHP-FPM with PHP7.0 (i.e. if you followed the 16.04 instructions): 

• sudo systemctl restart php7.0-fpm

If you are using PHP 7.2 (i.e. if using Ubuntu 18.04):

• sudo systemctl restart php7.2-fpm

To restart memcached: 

• sudo systemctl restart memcached

See:

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-php-fpm 
• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#restarting-memcached   
  

Finally, let's also repopulate the search index: 

• php symfony search:populate
• See:  https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/populate-search-index/

One last reminder: your web browser has its own cache as well! So either clear it, or do your initial testing in an incognito/private browser window, where caching is usually disabled by default. 

Let us know if this helps! 

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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/e0240869-2509-4e4e-87a7-8cdedea4e6db%40googlegroups.com.

[le...@orangeleaf.com]

Hi Dan,

Thanks for your help with this so far. 

I feel I should weigh in here to clarify the issue a little more.

Using RAD template as an example there are two fields in the edit form related to places.

Dates of Creation area -> Dates (place field)

and

Access points->Place access points

In the index area (the view we get after we save/cancel editing a record) we have 

Dates of creation area -> Dates (Place field)

Access points -> Place access points

At first glance this all appears correct.

However you will notice, that if you go to the edit form, and add a new place access point, and save it, it will not show up under place access points in the index view.

What the 'Place access points' is showing, is actually the 'Dates of creation places'. This, isn't right.

To further confuse the matter, the 'Dates of creation' section does not create an actual relationship with the Places. Only the 'Place access field' does this.

So if you have a place listed in Dates of Creation, that hasn't been added to 'Place access points' in the edit form, then when clicking it's link in the index view 'Place access points' section. You will get a listing of records linked to that place, but the record you just came from, is not actually listed there, because the relationship doesn't actually exist.

Here are steps to reproduce to clarify the issue.

1. Create a new rad record.
2. Add a new event to the 'Dates of creation' area, with a place of your choice.
3. Add a new place to the Place access points using a different place than used in Dates of creation.
4. Save and view the index screen (record overview)
5. You will see under 'Place access points' the place you added to Dates of creation, but not the place you added to 'Place access points'.
6. Click the link to the Place listed in place access points
7. The record you just came from will not show up in the resulting listing of records related to that place. Because the relationship doesn't exist.

I'm unsure of the expected behavior, but my best guess is that

1. Index view 'place access points' is supposed to display the related places listed in the 'place access points' field in the edit form.

2. Creating a dates of creation with a place is perhaps supposed to simultaneously add that place to the place access points in order to also create a relationship.

The first one seems obvious, the 2nd one, i'm not so sure about. I guess it's up for debate, but it seems that if a place is in an even (dates of creation in the case of rad) that it is in fact a 'related place' and so a relationship should be made.

I hope this clarifies the issue somewhat.

Kind regards

Leigh

To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.

[Dan Gillean]

Hi Leigh, 

Thank you for clarifying. I think I understand better what you are saying - but I actually see the opposite behavior (and I think this is the current intended functionality). That is to say, when I follow your steps 1-4:

• The Place access point appears in the view page as a clickable access point in the Access points area, as well as in the right-hand context menu
• The Events place term only appears in the Dates of creation area, and is not a hyperlink
• Both terms end up in the Places taxonomy, but only the Access point is shown as related to a description. You are only warned that the Events place is used in a description if you try to delete it from the taxonomy (as Melissa described in the original post of this thread) 

This is not a great design, but as far as I'm aware, this is how the feature was originally implemented in an early version of ICA-AtoM, and I don't believe any enhancements or fixes for this particular module have been sponsored since. 

Ideally, I think that the behavior would be more like so: 

• The Event place would end up in the access points area as well, but with a qualifier in brackets (for example, "Events place (Creation)" or similar) so it is contextualized
• Alternatively or possibly in addition, it would also show as a hyperlink in the Dates of creation area
• It would also appear in the right context menu under the "Related places heading"
• It would show in Places browse page as being related to the descriptions on which it is used in the Events module

There still remains the possibility that if we made these changes, we would be introducing something that looks like duplication into a lot of legacy user data when they upgrade - essentially, anyone who has added a Place in the Events dialogue but ALSO added the same place manually as a Place access point would end up seeing the place twice in the view page. So: some thought would need to go into implementation, and the effects it could have on users. 

Either way, it is frustrating that there's no way to see the related descriptions when managing terms in the Places taxonomy and a term has been created or linked via the Events module. It's also possible that this field in the RAD events dialogue shouldn't link to the Places taxonomy at all. Regardless of what approach we took to improve this, it would likely require some analysis and community sponsorship for us to be able to add some enhancements to a future release. 

Cheers,  

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

@accesstomemory

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/25abf0c4-1f15-4e05-98f3-693d0703e185%40googlegroups.com.

[Leigh Bicknell]

Argh! 😲 I'm Sorry Dan,

It turns out the 'events place' displaying under the access points listing was a bug I introduced myself as a result of a fixing a warning thrown in QubitInformationObject.php` while performing an export. Foolishly I used an `isset($options['events')` instead of an `!empty($options['events'])` in the `getPlaceAccessPoints()` method.

With regards to the relationships themselves, that's a debate for people more knowledgeable than myself.

Many thanks for your effort, am sorry to have wasted your time.

Regards

Leigh

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/axh2hPfA_d8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJ8fhnH7epOMTqkKzEv7%3DL-3rNxqcYEtQnmg6xS0TxbkA%40mail.gmail.com.

[Dan Gillean]

Ha! Thank you for clarifying and updating the thread, Leigh :)

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

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAEGZ0FRZw7BRwrU0ZwvCecv%2BXSp1r5mC54PMxiVBhGs_QofF3w%40mail.gmail.com.

[Clara Costa]

Hi Dan!

I think that the 'events place'  field should enter the information as it appears in the source (the document) :  

« RAD Rule “For an item, transcribe the place of publication, distribution, etc., in the form and grammatical case in which it appears.” (RAD 1.4C1). »

On the contrary, the places taxonomy and 'Place access points' should be used for standard terms.

This is a big problem because AtoM confuses the fields and thus creates unnecessary duplicates. 

The data entered in the 'events place' field should not be moved to the taxonomy field.

Is there any way to fix it? 

Thanks a lot.

Regards,

Clara

El dia dimarts, 5 de novembre de 2019 a les 16:16:54 UTC+1, Dan Gillean va escriure:

[ClaraC]

PS, I forgot to say that the same thing happens with the field  'events Actor name'.

This information should not be automatically copied to the index of taxonomies or "Name access points".

Can this be modified?  

El dia dimarts, 15 de setembre de 2020 a les 13:04:05 UTC+2, ClaraC va escriure:

[Dan Gillean]

Hi Clara, 

This is an interesting point. If you are directly transcribing information, then you may not want it to match a Place term in a controlled vocabulary, for example. 

It would be possible to change this in a future version of AtoM, but not without some complications - mainly for those users who are regularly using this field, and how we would successfully migrate the data. A migration script run during upgrade would need to do something like the following:

• Check for any Place term that has been used as a RAD event Place
• If it has, and has NOT been used elsewhere as a Place access point, then move it and delete it
• If it has AND it has also been used as a Place access point elsewhere, then make a copy and remove/replace only the event relations

This still may involve unexpected changes for some users, having terms in their Places taxonomy suddenly disappear. We always want to be very cautious about changes that could affect legacy user data!

Assuming we could work out a good strategy, I think it would be possible to move these to the property tables as key/value pairs, and keep them totally separate from the Places taxonomy. It does require analysis and development as I've indicated, so we would likely need to find a community sponsor for this work, to ensure we can give it the analysis necessary to find a solution that will work for all users. 

Regarding your second email about event Actors and authority records - here I disagree. When it comes to actors (i.e. persons, families, corporate bodies), we absolutely want to maintain separate authority records that can be reused for these. The RAD modal for adding creators might look different than the ISAD one, but the underlying intent and data model is the same.

We have made changes in more recent versions so that a creator is NOT automatically added as a name access point as well - a creator might not also be the SUBJECT of the records they created, and an archivist should be free to add these separately as needed. 

See for example: 

• https://projects.artefactual.com/issues/11828

We've gotten some feedback about this, and have made further changes so that the information might show up for display in the access points area, but it is NOT adding a "subject of" relationship on the authority record, as it was previously. See: 

• https://projects.artefactual.com/issues/12718
  

Essentially this means that in 2.6:

• A creator is not automatically listed as a subject (as is visible on the authority record view page, when looking at the related descriptions sidebar)
• Event actors (including creators) may show up in the Name access points area with qualifiers (e.g. "Name (creator)" for example), but this is only to make the relationship clearer for end users, and is not actually a name access point per se. Some event relationships (such as Publisher) may not display in the body of the record clearly currently, so this is a way of better displaying context only. 

More generally, in terms of maintaining authority control and not having to maintain two separate lists of entities (one for name access points and one for event actors such as creators, etc), I do think that they should both use the authorities as a source - otherwise you end up with different forms of name in each list, no way to add more information to an actor record (if it's treated as a term, then there's no dates of existence, history, etc), and so on. 

I'm not sure if that was clear - if not, I apologize, and I can try again! 

Regards, 

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/10e2177f-5fd8-4be7-8702-d3a9606cfd43n%40googlegroups.com.

[ClaraC]

Hello Dan,

it would be great to be able to solve the taxonomy of places. I hope to hear from you about it. 

As for the taxonomy of names, I fully agree that keeping two lists is not operational and can lead to inconsistencies and duplicates. Therefore my suggestion was: 

1. Everything entered in ‘Creation date area’ that is non-standard information without generating lists. 

2. Always use "Access points" for standardized information at the discretion of the cataloger (only this field is the one that automatically generates the list of taxonomies). 

In this way we will be able to standardize the name of an editor in Access Points and retrieve all the descriptions associated with it regardless of how they appear in the printed document. 

The problem that I see is that if we use the RAD template, the information related to the publication data (if I'm not wrong) must be entered in the 'Creation date area' and specifically in the 'editor' field. If we follow the rules for such information (RAD 1.4) a lot of information noise is generated in the list of authorities for entities. 

When we catalog, the name of the publisher only appears in this field, which does not happen with creators or other actors since their name usually appears in other fields of the description. Publishers vary the way they specify their name in publications throughout their history and that is why the cataloger, if he follows the cataloging rules and enters the name in the 'editor' field, a list is generated in AtoM with the same editor written in various ways. 

I do not know if I am confused or if there are other fields where to specify this type of information but if there are no more options in AtoM, what comes to mind is to enter the name of the editor as it appears in the document in a 'notes' field but this would not be entirely correct.

I await your recommendations. 

Thank you so much.

Regards, 

Clara  

El dia dimecres, 16 de setembre de 2020 a les 17:34:39 UTC+2, Dan Gillean va escriure:

[Dan Gillean]

Hi Clara, 

I think we've reached agreement about the Place field in the RAD edit template - though changing the current behavior would require sponsorship, and careful analysis not to negatively impact existing user data when upgrading. I would love to hear from other users if they agree with this perspective!

Using the RAD template for published materials, and capturing details such as publisher etc, does present some challenges. I believe I understand what you're describing, but I'm not sure what to suggest! 

Part of this stems from the history of the RAD standard itself, and the intended focus of AtoM. 

There is an excellent history of the Canadian RAD standard written by Richard Dancy, available freely in Archivaria here: 

• https://archivaria.ca/index.php/archivaria/article/view/13406/14711
  

The short version: RAD was created before the ICA had created international standards such as ISAD(G), and as such, was one of the first national archival description content standards. Lacking a model for creating such a standard, archivists at the time essentially copied the AACR2 library cataloguing standard, added a bunch of elements in a "Notes" section specific to archives, and left much of the rest mostly untouched. 

As a consequence, there are a lot of elements in RAD that have to do with published materials, and that rarely apply to typical archival material (i.e. primary documents) - for example, Standard Number is generally an ISBN; and most archival documents don't have a "Statement of responsibility" etc...

In adding support for RAD, AtoM of course needed to cover all available core RAD fields. However, AtoM's intent has always been focused primarily on archival management, and not the management of published materials. Thanks to RAD we have all these fields related to published materials, but the user experience for them is not very great, because AtoM prioritizes workflows that help archivists (such as treating linked actors as authorities, so they can be reused and given standard forms of name, etc). 

I think there are probably some good workarounds and strategies to make cataloguing work in AtoM, but it's true that some workflows are more challenging, because early design decisions made in the RAD implementation heavily favor archival workflows.

I would say that if you're using AtoM for cataloguing, then it would probably still make sense to treat the "publisher authorities" as true authorities and choose a standard form of name (that everyone will use for linking), and then capture variations in the names over the years in some of the other form of name fields. It's true that this contradicts part of RAD, which is not ideal... but remember, much of RAD, when its history is understood, doesn't really apply to archival materials as we think of them (as in unique primary records). 

Using a notes field is also a fine idea if this makes the management easier for you - I think you'll just need to come up with some consistent internal policies and documentation so that all users are following the same process and rules, using the same notes field, etc.  

In terms of development, I'm not clear how we could improve the situation  for publishers without either a) making AtoM harder to use for archivists (i.e. no longer controlling authorities), or else b) trying to make AtoM cover a whole other domain (library-like cataloguing), for which there are many other applications better suited to this. Perhaps long term you might consider finding a good cataloguing solution in another program, and considering how best to link cataloguing entries created there to descriptions managed in AtoM when necessary?  Otherwise, I'd probably suggest a custom plugin, so any custom templates or fields can be kept separate from the current data model and forms. 

As you can tell, I'm not sure what the best course is. I would welcome input from other community members! 

Cheers, 

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/de952748-5dd3-4534-befa-60eaa4d7495en%40googlegroups.com.

[ClaraC]

Thanks, Dan!
We currently have approximately 350 printed items described in the RAD template, so any contribution is welcome. 

Just two last questions :

1. After upgrading to 2.6, access points by name generated from creation-events are not displayed in RAD (in version 2.4 they were displayed).

2. Do you know when this bug will be made? The name access points continue to be viewed as "subjects of ..." https://projects.artefactual.com/issues/12718 

Thanks again,

Clara

El dia dimarts, 22 de setembre de 2020 a les 23:59:10 UTC+2, Dan Gillean va escriure:

[Dan Gillean]

Hi Clara, 

1) Sounds like a new bug to me. I wasn't able to recreate it when adding one actor relation at a time, but if I tried to add multiple events, then I was able to reproduce. I've filed an issue ticket here: 

• https://projects.artefactual.com/issues/13425
  

Does this actively describe what you mean?

Regarding 2), I have re-tested and confirmed that this duplication is still taking place. I have updated the issue in the hopes of bumping it forward. I have also filed a separate Wishlist issue, that captures a few ideas on how to better improve the visibility of non-creator actor relations in the RAD template. See: 

• https://projects.artefactual.com/issues/13424
  

See also this older Wishlist ticket, created when #12718 was first discovered. It involves allowing users to qualify name access points directly from the name access point area, which would add a second way of doing this for RAD template users, as well as adding an easier method for adding non-creation relationships for other templates (currently the only way is to go to the authority record and add the relation there, in the Relationships area). See: 

• https://projects.artefactual.com/issues/12719
  

We will try to address #12718 for the 2.7 release. However, as you may know from our business model, this is no guarantee. For Wishlist tickets, we will definitely need community support to implement them, either via community sponsorship or via code contributions. If #12718 or any of the Wishlist proposals are a priority for your institution and you would like to sponsor  development so we can prioritize their inclusion in the next release, please feel free to send a message to in...@artefactual.com and our team can prepare a development estimate for you. For more on how Artefactual manages AtoM, see: 

• https://wiki.accesstomemory.org/Development/Philosophy
  

Cheers, 

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/4114d844-02aa-49b7-a8ee-bc64b2e8b143n%40googlegroups.com.

[ClaraC]

Hi Dan!

Completely agree. Both, 1 and 2 fully describe what I wanted to say .

Thanks for your contributions and aids.

Cheers,

Clara

El dia dilluns, 28 de setembre de 2020 a les 16:45:30 UTC+2, Dan Gillean va escriure:

[cher...@ualberta.ca]

Hello Dan and All,

We bumped into the same issue when cleaning our Place taxonomy - we have many terms in it that are not linked to any descriptions but are present in the Dates of creation of archival descriptions. Since the conversation in this thread took place over four years ago, I was wondering whether the issue was addressed in the later versions of AtoM. I wasn't able to find this information myself, so I just wanted to confirm with you. 

Thanks,

Maryna Chernyasvka

Digital Archivist

University of Alberta Archives

[Dan Gillean]

Hi Maryna, 

While it looks like some of the more immediate bug reports have since been addressed in some way (#13424. #12718), the underlying issue of Places added in the RAD event pop-up has not been addressed directly. Even just scrolling through all the discussion on this thread reminds me that the issue is a bit more complex than it initially seems, and needs some care in how it's fixed. For now, I have let the Maintainers know this is an ongoing issue worth consideration! 

Cheers, 

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/5ceed883-9bb9-40c3-b136-f9e64f76740bn%40googlegroups.com.

[Maryna Chernyavska]

Thanks Dan.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLCrPK%3DjuXZ%3Dp_ZL9aYkK%2BjeseZfaG2J6dqHPA_W1GpPQ%40mail.gmail.com.