Inheritance of repository is not made until publication

[Patricia McGuire]

Another problem we've noticed with searching is that when you do an advanced search on a collection that has draft status, and restrict it to a particular repository, the searched term is not found unless it is at the very top level (or maybe it's if it's at fonds level, I haven't tested all possibilities). When you publish the catalogue, AtoM can find the searched term at all levels. When you return the catalouge to draft status, AtoM can still find the searched term at all levels. Some of our contributors will never publish their catalogues, they will only use it in-house, so though there is an obvious workaround we'd like to get it so that search works in draft status.  I'm ready to provide examples, and access information to our site, off-group.

-Patricia McGuire
King's College
Cambridge, UK

[Dan Gillean]

Hi Patricia,

Thanks for reporting this. I believe I understand what you mean, but I would be happy to receive further examples from you, to be able to test in our development environment and open an issue ticket. If possible, the most useful way to receive this kind of information would be the methodology we try to use in our issue tracking system:

1) To reproduce: Include step-by-step instructions that would allow a developer or systems analyst to reproduce the error. Even if the example involves searching a term particular to your installation, it gives us a sense of what actions must be performed to isolate similar behavior in our installation of the application.

2) Resulting error: The issue that was encountered - what actually occurred.

3) Expected result: What should have happened if the software was behaving as expected.

Feel free to add any further notes that would help clarify the problem. It also helps us to know exactly what version you have installed (you can find this by navigating to Admin > Settings > Global - the first field in the list will tell you your application version), and what browser you were using. Any other installation or configuration details that might affect the behavior of the application would also help.

I intend to test this in our development branch, rather than your installation (to ensure that it is a problem that is application-wide, rather than installation-specific), so no need to send credentials at this stage. You are welcome to describe the use case here, or contact me off-list (d...@artefactual.com), and I will investigate further as I am able.

Another possibility, if you are interested in testing the application further and helping us to identify issues, would be to register an account in our issue tracking system, Redmine - https://projects.artefactual.com/account/register

This way you can file issue tickets yourself - someone here will then test to reproduce, and further categorize the ticket appropriately.

Thanks again!

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/4ae683ae-e531-47b9-8733-0c5f8a848008%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Patricia McGuire]

Dan,

Thanks again.  I am running AtoM application version 2.0.1 - 102 using Firefox 26.0.

1. To reproduce the error: Create an EAD catalogue with at least two levels, where the top level has a search word in it, say manglewurzle (no italics), and also a record at a lower level, in my case it's two levels down, which has the same search word. Log into an environment/set-up of AtoM which has at least two institutions - log in as administrator (that gives you the greatest number of permissions allowed doesn't it? that's what I'm logged in as). Set AtoM to default to draft status upon upload (Admin > Settings > Global > Default publication status: [select the] Draft [radiobutton]). Upload the EAD catalogue (Import > XML and then Browse to the EAD catalogue you want, then click Import). Ensure that it gets attached to one of the repositories in your environment, say ABC Record Office (browse to the new catalogue's top level description, click Context Area, find the Repository field and if it's not ABC Record Office then start typing ABC, then select the ABC Record Office from the drop down menu). Save that change (at the bottom of the webpage). Search for manglewurzle limited to ABC Record Office. (I can reproduce the problem whether using quicksearch with the particularly repository's radiobutton selected, or in advanced search with selecting the faceted search for that repository.)

2: Resulting error: You get one hit, namely the record at the top level.

3. Expected result: two hits. I expect this because of the following:

Search without limiting to the repository ABC Record Office and you get two hits, the top level and the lower down one. Click on either one and you'll find that in the Context area, the Repository is listed as the ABC Record Office.

Or, publish the catalogue (browse to its top level, click on, say, Description Control Area, then click on Administration Area at the bottom of the webpage and in the Publication Status box select Published from the drop-down-menu). Repeat the search for manglewurzle limited to the ABC Record Office, and you get two hits.

An additional curiosity is that when you return the catalogue to draft status, then do the search for manglewurzle limited to the ABC Record Office, you get the two hits.

In my case I uploaded the EM Forster papers catalogue, and while it was still draft-status searched for forster photograph limited to King's College, and came up with only one hit, the top level one http://ec2-54-196-124-87.compute-1.amazonaws.com/index.php/papers-of-edward-morgan-forster. When I published then searched for Forster photograph limited to the King's College Archives repository I get 1601 hits, which is probably most of the EMF/27 series.

Ooh, I just realized I didn't do a global search while in draft status. There are another 1000 hits for forster photograph in non-King's papers, so it would be interesting to know how many hits I get with a global search with the Forster catalogue in draft status. But having published the catalogue, and it takes so long to delete and re-upload I'll have to do it another day. I'll let you know.

The problem occurs also if there is no hit at the top level, for example if you search our AtoM for 'cellar' you find http://ec2-54-196-124-87.compute-1.amazonaws.com/index.php/search?query=cellar&repos= exactly four hits (even if you restrict to the Cambridge University Archives repository), all at lower levels of the Footlights Dramatic Club, owned by the Cambridge University Archives, but when it was at draft status you got no hits when restricting to that repository.

I've tried to register for Redmine, and thought I got the 'you successfully registered' note, but can't log on. Perhaps there's a time lag, I'll try again tomorrow.

-Patricia

[Jessica Bushey, AtoM Product Manager]

Dear Patricia,

My name is Jessica Bushey, I am the other AtoM Product Manager at Artefactual Systems. I have spent a good deal of time testing for the behaviour you have described, using Firefox 26.0 and AtoM 2.0.1 - 107, which is our current testing site and using Firefox 26.0 and AtoM 2.0.1-102, which is our current demo site, available here: http://demo.accesstomemory.org/. Unfortunately, I am unable to reproduce the inconsistencies you were finding between draft status and published status, between fonds-level and lower levels, and as a global search vs. a specific repository search. In all the tests I performed the search results accurately reflected the # of instances in which they existed (in both the scope and content, or the title), regardless of the status of the description (draft or published), or the level in which the term is being searched existed (fonds, series etc.).

Is it possible for you to test your site using a short and simple example? For example, a fonds-level description with two levels of children (A & B), with a search term existing at the fonds-level and at A series and another search term existing only B series. Test this at draft and published and see what your results are. Then you can send me the EAD and I will import and test again to see if I can replicate the problematic behaviour. This will be a more effective approach to troubleshooting your site. That way I can review your EAD and see if that is where the problem is resulting. But the shorter and simpler the better.

Regards,
Jessica Bushey

[Patricia McGuire]

Dear Jessica,

Thank you for your prompt testing and response. I have created a new small catalogue as you suggest, but this time through the AtoM interface, and not been able to reproduce the error. I will create the same catalogue on my usual MS Access system, output it as EAD, and compare the EAD report output by AtoM  with the EAD we're trying to import, to see if I can identify it as a tagging issue.

-Patricia

[Jessica Bushey]

Dear Patricia,

I am interested to hear about your findings. We have been doing extensive testing of our EAD import and EAD export in AtoM, with a number of fixes and increased functionality being performed over the past year. I recommend comparing your EAD prior to import, the actual AtoM record and all its information, and then comparing the EAD after export from AtoM. That will give you the fullest sense of what is going on. One thing to be aware of, you may be including information in your EAD file that is not compliant with ISAD(G) elements of archival description, or is using an EAD tag that AtoM does not support. If this is the case, the information is most likely being lost upon import into AtoM. 

Regards,

Jessica Bushey

---

Jessica Bushey, MAS
AtoM Product Manager

Systems Analyst
jes...@artefactual.com

Artefactual Systems Inc.
www.artefactual.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/90cb7cd0-dec6-4775-bf7a-5c6b11a89386%40googlegroups.com.

[Jessica Bushey]

Patricia,

One more thing, although this is a work in progress, you might find the ISAD(G) to EAD crosswalk on our wiki documentation helpful: https://www.qubit-toolkit.org/wiki/Crosswalks. 

Regards,

Jessica 

---

Jessica Bushey, MAS
AtoM Product Manager

Systems Analyst
jes...@artefactual.com

Artefactual Systems Inc.
www.artefactual.com

On 2014-02-11, at 7:30 AM, Patricia McGuire wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/90cb7cd0-dec6-4775-bf7a-5c6b11a89386%40googlegroups.com.

[Patricia McGuire]

Dear Jessica,

Thanks, I will do. We already know that some of our data, though proper EAD, is being ingested but not processed by AtoM as it was in our system (e.g. we code our repositories using simply <repository>King's College Archive Centre</repository> rather than using any <corpname> details and that's part of why AtoM isn't linking the catalogues to the repositories, but we'll figure out how to code for the link to be automated, and we don't code the repository at each record of the catalogue which is probably part of the problem discussed below).  As it's not of universal importance, I will discontinue posting here on the subject.

-Patricia

[Dan Gillean]

Patricia,

Thanks for the report back. Ultimately, we want to make AtoM's EAD import script as flexible as possible - so long as the EAD itself is valid and conforms to the schema's expectations, it should import. Not all EAD elements are supported in AtoM (for example, stylistic elements such as <table>, <emph>, or currently the <index> element are not supported - there are others as well), but for those that have mappings, we hope to make the import process behave consistently regardless of local variations in encoding practices.

Consequently, so we can keep track of this, I have filed a bug report in our issue tracking system - see: https://projects.artefactual.com/issues/6317

Though it is *tentatively* scheduled for 2.0.2 at this time, so we can keep track of it, there are currently 38 open tickets associated with 2.0.2, and none of them are sponsored at the moment. As such, we can make no promises about if or when this issue will be fixed. Nonetheless, I appreciate hearing this kind of feedback, and hope that it is something we can improve in AtoM in the near future.

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/638d677f-62cb-4ccd-8149-f6ba779aba4a%40googlegroups.com.

[Patricia McGuire]

Dear Dan and Jessica,

I'm delighted to report that once I put a <corpname> tag in, at the highest/fonds level (it is not necessary to put it at every level of the catalogue), it resolved both these errors - linking to the right repository on upload, and finding searched-for text in sublevels of never-published records.

Thanks again,

-Patricia

[Jessica Bushey]

Dear Patricia,

So happy to hear your news of success.

Thank you for letting us know about this approach to the problem you were experiencing.

Regards,

Jesisca

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ac18354b-736d-4095-9afa-17e5b31f5328%40googlegroups.com.