Physical Location files become items

[buck...@gmail.com]

Hi all,

I'm having a strange issue where half way through a CSV import, the physical locations that the CSV lists as "file" are listed as "item". I triple checked the CSV and all the entries have the same information: Box|File in the physicalObjectType column and P44|16 (for example) in the physicalObjectName column. The import is for 1020 rows, all of which are items directly under a collection. The first couple hundred or so correctly list "File: 16" (for example), but then all of a sudden the rest say "item: 17". I looked at exactly where the change occurs and could find no differences. Does anyone have any idea what could be causing this?

AtoM 2.4

Thanks,

Jarad

[Dan Gillean]

Hi Jarad, 

Wow, that is a very strange error! I've not seen that one previously. 

Would you be willing to share the CSV file that you were using, so I can try to reproduce this issue locally? Feel free to send it to me off-list if you prefer. I will try to recreate the issue, and if I can, I'll file a bug ticket so we can look into it further. 

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/4ee2114e-7da7-4d9b-a9f3-daba3157523c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Gillean]

Hi Jarad, 

I've received your file; thanks!

I haven't had a chance to run tests yet, and I don't see anything at first glance that would definitely lead to this issue, but I did want to provide a couple thoughts and suggestions. 

First, I noticed that while you have piped the name and type physical object values in the CSV, you didn't pipe the location - meaning that half of these entries are ending up without a location defined. AtoM has been known to behave strangely when some of the physical storage data is missing, so there is a small chance that this relates to your issue. 

I also wanted to point out that, due to the current limitations of the AtoM physical storage module (in which we have no hierarchical organization), many of your file level containers will end up in the same big bucket. What I mean is, on the archival description you'll have 2 locations  (a box and a file) linked, but because the container names are not individually unique, when you click on the location for the file, you will find many descriptions listed in from other file containers that share the same name. 

For example, one row has OP01|6 for the Box|File values in the physicalObjectName column. On the description, with the data you have now, you'll see something like this: 

However, in AtoM's physical storage module, there's no actual relationship between that box, and that folder (and unfortunately, no way to make one at this time) - they are just 2 different containers. 

This means that as the import progresses, when AtoM finds the next value that has 6 as the File value, it will link that folder to the existing location - so when you browse the physical storage module, you'll end up seeing file 6 from not just OP01, but also P01, P03, P04, etc. 

If that doesn't bother you (for example, if you are only going to use the information on the description view page, and don't intend to use the physical storage module directly), you can ignore this. But I have shared a few previous thoughts on strategies to work around this: 

• https://groups.google.com/d/msg/ica-atom-users/fZyu_z4H1IM/mhmihSNYCAAJ
  
• https://groups.google.com/d/msg/ica-atom-users/ZaNWemSct6U/5SsKtp--BwAJ
  

Finally: did you manually add File to the Physical Object Type taxonomy, or did you just use the import to create the new type on the fly? The default term is "Folder." Technically, it should be fine adding a new term to the taxonomy by importing it, but it's one more place where there could be buggy behavior, so just trying to figure out possible vectors to explore :)

I will try to modify your CSV a bit so I can import it locally soon! 

Regards, 

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

@accesstomemory

On Fri, Aug 17, 2018 at 12:27 PM, Dan Gillean <d...@artefactual.com> wrote:

Hi Jarad, 

Wow, that is a very strange error! I've not seen that one previously. 

Would you be willing to share the CSV file that you were using, so I can try to reproduce this issue locally? Feel free to send it to me off-list if you prefer. I will try to recreate the issue, and if I can, I'll file a bug ticket so we can look into it further. 

Regards, 

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

@accesstomemory

On Fri, Aug 17, 2018 at 11:44 AM, <buck...@gmail.com> wrote:

Hi all,

I'm having a strange issue where half way through a CSV import, the physical locations that the CSV lists as "file" are listed as "item". I triple checked the CSV and all the entries have the same information: Box|File in the physicalObjectType column and P44|16 (for example) in the physicalObjectName column. The import is for 1020 rows, all of which are items directly under a collection. The first couple hundred or so correctly list "File: 16" (for example), but then all of a sudden the rest say "item: 17". I looked at exactly where the change occurs and could find no differences. Does anyone have any idea what could be causing this?

AtoM 2.4

Thanks,

Jarad

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

[buck...@gmail.com]

Hi Dan,

Thanks for taking a look. I was aware of the box situation in terms of the lack of hierarchy. I'm not huge on having it show all items in folder "3", for example, but I was using it anyways just so it showed the location in the description in an intuitive way and so it will look better when I get around to generating finding aids.

I was not aware of needing to pipe the location. I figured it was just a general overall location of the material, but I guess that does assume it's altogether when they may not be the case, so that's my bad. If you can't figure out anything else wrong with it, I'll try piping that properly and see if that helps at all.

Let me know if you find anything else.

Thanks!

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