Item level of description

[Martin Holmes]

I'm building a multi-repository db which has content from multiple museums. The things we're importing are all at the Item level (typically), and don't have containing levels such as Fonds, because they're from small museums. However, if I assign the level "Item", I get this warning:

Level of description - Value "Item" is not consistent with higher levels.

There are no higher levels other than the repository itself. What's the appropriate approach to take here? If I put nothing in that field, I get a warning that it's a mandatory field.

Cheers,
Martin

[Dan Gillean]

I would just ignore this, Martin.

I'm not sure which standards template you are using, but I'm guess that it is ISAD(G) (the default template), or RAD or DACS. The warnings in AtoM are based on the content standards, and they were implemented very early on in AtoM development - so they are a bit literal-minded. Note that your public users will never see these warnings. Keep assigning them the level of description you want to use (in this case, items), and don't worry about the warnings - they are meant to encourage standards compliance, but there are certainly valid cases where an item is the top-level of description, so I wouldn't worry.

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at http://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/5e93c094-a6e3-41c5-892c-42652f976fc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Holmes]

That's good to know. We're using RAD.

Thanks indeed,
Martin

[Creighton Barrett]

I'm not sure if it makes a difference (because, as Dan says, the warnings don't really matter), but we have a single repository site with items as the highest level of description and do not get these warnings. We're using RAD but I just checked with ISAD(G) and don't have the warnings with that template either.

Cheers,

Creighton

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/1ed8445f-e9c1-404e-9c99-906e13c8635b%40googlegroups.com.

[Dan Gillean]

Hi all,

Creighton, your post got me curious, and so I went and performed a number of tests in our 2.2.x instance. In the end, you're right - no matter what I tried, I couldn't seem to make a standalone, top-level item record generate a warning. I tried creating them via the user interface, importing as EAD, and importing via CSV, to make sure there is not some difference in how the record is created for each process, that might lead to a different outcome. In the end, I asked one of our developers to check out the code for me.

Regarding warnings for levels of description, there are only a couple of checks in place. A collection added as a child of a fonds will produce a warning, as will a fonds or subfonds added as the child of a collection. If you add an item as the child of another item, you will get the following warning - the only item level one I could generate:


​

Note that this warning was on the child item record however, *not* on the top-level item record. If I added a "part" record as a child of an item, I did not receive any warning.

The only possibility that our developer could think of, that might lead to standards-compliance warnings for an item-level record as a top level of description is if someone has used a SQL query to update all descriptions to items.

In AtoM, there is a root information object that acts as the parent to all archival descriptions in the database. A SQL query that sought to update all records to item might inadvertently also update this root node - which would then mean that top-level item records available via the user interface would actually, on the back end, be children of another item record, thereby producing the warning.

My only other theory is that, in creating your multi-institutional records, you have somehow created the archival institutions as a different entity type - such as an information object (e.g. archival description), rather than creating a repository (archival institution) record that is linked to the appropriate description(s). It's also possible that there might be some edge case we haven't found where a collection that links to multiple different repositories at different levels might produce a strange result - I'm not sure.

Martin, do either of these theories sound possible, based on what you've been doing? Is your AtoM instance publicly accessible by any chance, so I might take a look?

I would be very interested in solving this little mystery - but fortunately, since the warnings are not enforced, you can continue to ignore them if we can't solve the problem. For the long-term maintenance of your AtoM instance though, I think it would be really useful to figure out what has occurred now.

Regards,

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

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

[Martin Holmes]

HI Dan,

I have made changes records in the SQL db; I don't really have any alternative, because I'm importing hundreds of records and will eventually be dealing with thousands, so changing things one by one in the admin interface is not practical. It's certainly possible that I've screwed something up there, but the records do appear correctly as belonging to the repository, and the repository is definitely a repository (it has all the repo information such as address etc., as well as the logo). Does your developer have any idea about what I might have borked in the db to cause this? I'm still figuring out how the database actually works, and there are an awful lot of numeric ids to keep track of.

Cheers,
Martin

[Dan Gillean]

Hi Martin,

I mentioned Radda's leading theory in my last post:

The only possibility that our developer could think of, that might lead to standards-compliance warnings for an item-level record as a top level of description is if someone has used a SQL query to update all descriptions to items.

In AtoM, there is a root information object that acts as the parent to all archival descriptions in the database. A SQL query that sought to update all records to item might inadvertently also update this root node - which would then mean that top-level item records available via the user interface would actually, on the back end, be children of another item record, thereby producing the warning.

I will see if he can potentially add to this thread with further details, or thoughts on how to resolve.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com.

[Martin Holmes]

Thanks Dan. It's possible that I did touch the root info object (it's id
1 in the table, right?). That has no data in it except its id,
local_identifier, level_of_description (227, like all the others), flt,
rgt and source_culture; all the rest are NULL. Would that 227 be wrong?

Cheers,
Martin

On 15-05-14 03:13 PM, Dan Gillean wrote:
> Hi Martin,
>
> I mentioned Radda's leading theory in my last post:
>
> The only possibility that our developer could think of, that might
> lead to standards-compliance warnings for an item-level record as a
> top level of description is if someone has used a SQL query to
> update all descriptions to items.
>
> In AtoM, there is a root information object that acts as the parent
> to all archival descriptions in the database. A SQL query that
> sought to update all records to item might inadvertently also update
> this root node - which would then mean that top-level item records
> available via the user interface would actually, on the back end, be
> children of another item record, thereby producing the warning.
>
>
> I will see if he can potentially add to this thread with further
> details, or thoughts on how to resolve.
>
> Cheers,
>
> Dan Gillean, MAS, MLIS
> AtoM Product Manager / Systems Analyst,

> Artefactual Systems, Inc <http://www.artefactual.com/>.
> 604-527-2056
> @accesstomemory <https://twitter.com/accesstomemory>

>
> On Thu, May 14, 2015 at 11:54 AM, Martin Holmes <martin...@gmail.com
> <mailto:martin...@gmail.com>> wrote:
>
> HI Dan,
>
> I have made changes records in the SQL db; I don't really have any
> alternative, because I'm importing hundreds of records and will
> eventually be dealing with thousands, so changing things one by one
> in the admin interface is not practical. It's certainly possible
> that I've screwed something up there, but the records do appear
> correctly as belonging to the repository, and the repository is
> definitely a repository (it has all the repo information such as
> address etc., as well as the logo). Does your developer have any
> idea about what I might have borked in the db to cause this? I'm
> still figuring out how the database actually works, and there are an
> awful lot of numeric ids to keep track of.
>
> Cheers,
> Martin
>
> --
> You received this message because you are subscribed to the Google
> Groups "ICA-AtoM Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ica-atom-user...@googlegroups.com

> <mailto:ica-atom-user...@googlegroups.com>.

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

> <mailto:ica-ato...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/ica-atom-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com

> <https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "ICA-AtoM Users" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ica-atom-users/uNc34J79NBo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ica-atom-user...@googlegroups.com
> <mailto:ica-atom-user...@googlegroups.com>.

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

> <mailto:ica-ato...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/ica-atom-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKEgpyn19o8REUyBDHoiYviqJM2HyxVB6ECiOH5bObvqQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKEgpyn19o8REUyBDHoiYviqJM2HyxVB6ECiOH5bObvqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[raddao...@gmail.com]

Hi Martin,

you are right. Setting the level_of_description to NULL for the information object with id=1 should fix this problem.

Regards.

>     <mailto:ica-atom-users+unsub...@googlegroups.com>.

>     To post to this group, send email to ica-ato...@googlegroups.com
>     <mailto:ica-ato...@googlegroups.com>.
>     Visit this group at http://groups.google.com/group/ica-atom-users.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com
>     <https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>     For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ICA-AtoM Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ica-atom-users/uNc34J79NBo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ica-atom-user...@googlegroups.com

> <mailto:ica-atom-users+unsub...@googlegroups.com>.

[Martin Holmes]

On 15-05-15 09:00 AM, raddao...@gmail.com wrote:
> Hi Martin,
>
> you are right. Setting the level_of_description to NULL for the
> information object with id=1 should fix this problem.

That worked. Had to disable foreign key checks and re-enable them in
order to do it.

Many thanks!

Cheers,
Martin

> <martin...@gmail.com <javascript:>

> > <mailto:martin...@gmail.com <javascript:>>> wrote:
> >
> > HI Dan,
> >
> > I have made changes records in the SQL db; I don't really
> have any
> > alternative, because I'm importing hundreds of records and will
> > eventually be dealing with thousands, so changing things one
> by one
> > in the admin interface is not practical. It's certainly possible
> > that I've screwed something up there, but the records do appear
> > correctly as belonging to the repository, and the repository is
> > definitely a repository (it has all the repo information such as
> > address etc., as well as the logo). Does your developer have any
> > idea about what I might have borked in the db to cause this? I'm
> > still figuring out how the database actually works, and there
> are an
> > awful lot of numeric ids to keep track of.
> >
> > Cheers,
> > Martin
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "ICA-AtoM Users" group.
> > To unsubscribe from this group and stop receiving emails from
> it,

> > send an email to ica-atom-user...@googlegroups.com <javascript:>
> > <mailto:ica-atom-user...@googlegroups.com
> <javascript:>>.

> > To post to this group, send email to

> ica-ato...@googlegroups.com <javascript:>
> > <mailto:ica-ato...@googlegroups.com <javascript:>>.

> > Visit this group at
> http://groups.google.com/group/ica-atom-users

> <http://groups.google.com/group/ica-atom-users>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com
> <https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/ica-atom-users/7b1261da-e2e8-4fb7-b3d6-07478a7afce2%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> >
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

> >
> >
> > --
> > You received this message because you are subscribed to a topic
> in the
> > Google Groups "ICA-AtoM Users" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/d/topic/ica-atom-users/uNc34J79NBo/unsubscribe

> <https://groups.google.com/d/topic/ica-atom-users/uNc34J79NBo/unsubscribe>.

>
> > To unsubscribe from this group and all its topics, send an email to

> > ica-atom-user...@googlegroups.com <javascript:>
> > <mailto:ica-atom-user...@googlegroups.com <javascript:>>.

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

> <javascript:>
> > <mailto:ica-ato...@googlegroups.com <javascript:>>.

> > Visit this group at http://groups.google.com/group/ica-atom-users

> <http://groups.google.com/group/ica-atom-users>.

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

> <https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKEgpyn19o8REUyBDHoiYviqJM2HyxVB6ECiOH5bObvqQ%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKEgpyn19o8REUyBDHoiYviqJM2HyxVB6ECiOH5bObvqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>

[Sunny Lee]

We had a similar issue with some series of a fond (id 65186) which belongs to an institutional repository. 

The fond has four series (Series 1, Series 2, Series 3, and Series 4) and Series 2, 3, and 4 returned `The level of description - Value "Series" is not consistent with higher levels` error when logged in. 

In the information_object table, there were some orphaned objects with identifier value starting with "2015.03V 2" and the error message was disappeared after deleting them from the information_objects table. However, the AtoM generated PDF finding aid is still showing incorrect Ref Code for series 2, 3, and 4. I ran `php symfony propel:build-nested-set` and `php symfony cc` and that wasn't helpful. 

Ref Code for Series 1: 2039-1 <- This is correct.

Ref Code for Series 2: 2039-2015.03V 2-9-2 <- It should be 2039-2

Ref Code for Series 3: 2039-2015.03V 2-9-3 <- It should be 2039-3

Ref Code for Series 4: 2039-2015.03V 2-9-4 <- It should be 2039-4

2039-2015.03V 2-9-2, 2039-2015.03V 2-9-3 and 2039-2015.03V 2-9-4 are in fact child description of the Series 1. 

Does anyone know how this data corruption can be further corrected? 

Thank you for any advice in advance.

Finding aid which has incorrect ref code for Series 2, 3, and 4:  

Orphaned objects which were deleted from the informatin_object table:

Those selected in dark grey background which doesn't have a parent_id value have been deleted. 

Thanks,

Sunny

[Sunny Lee]

This turned out to be a caching problem. After purging the pdf url using command-line (curl -X PURGE pdf_url), I was able to view the updated finding aid which has the corrected ref codes for Series 2, 3, and 4. 
Thanks for the helpful post. 

Sunny

[Dan Gillean]

I'm glad this turned out to be a simple issue after all - thanks for updating the thread to let us know you'd solved the issue, Sunny! 

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/1e027302-a7e9-4012-9e00-3f873e341071%40googlegroups.com.