Repository records - additional access points and facets
|Assignee:||Dan Gillean||% Done:|
|Target version:||Release 2.1.0|
|Google Code Legacy ID:||Tested version:||2.1|
This expands on feature #3903 and the existing implementation in 2.0 (to be developed by USask).Currently in 2.0, when browsing archival institutions there are facets for:
- archive type
- region (i.e. province in the Canadian context)
- geographic subregion (e.g., Southwestern Saskatchewan, Northern Saskatchewan)
- thematic area (e.g., Agriculture, Local/regional history, Aboriginal peoples)
- locality (city/community)
- geographic subregion
- thematic area
This feature is currently implemented as a customization in SAIN (1.3.1), so needs to be integrated into the 2.x structure. The faceted searching should make that integration a bit easier. Current implementation:
Related issue: Improve facet usability - #5278
#4 Updated by Tim Hutchinson over 8 years ago
I just wanted to check in about this issue - it's next in line for USask development (Steve has #3899 just about ready to submit).
First, you updated the issue before without comment so I assume you have no questions/concerns... but I just wanted to make sure that's the case. I think this one is pretty straightforward, but please let me know if anything needs discussion.
Second, I'm wondering whether there is any value in splitting this issue into subissues for submission, e.g.:
- add locality facet
- add taxonomies for thematic area and geographic region
- add thematic area and geographic region to ISDIAH template
- add facets for thematic area and geographic region
(or some combination)
This will perhaps be more relevant for #5968 which is much more elabourate, but I'm mostly asking what will be easiest at your end when we submit code for review. Is it better to tackle the whole issue at once, or in pieces?
As part of this we will also look at #5982, referenced above - current bug with the region facet which will also affect locality.
#5 Updated by Dan Gillean over 8 years ago
Hi Tim! Glad to see that this is moving ahead, it's very exciting!
I have previously checked out the functionality of the SAIN customization, so I feel pretty clear on what you are doing here - hence no questions. Looking forward to seeing this in AtoM 2!
I've checked in with Jesus about submitting the code - he feels it can all be managed on one issue ticket. The ideal solution for him would be to make up the pull request with a number of smaller commits - each commit relating to one aspect of the development (e.g. add locality facet) with its own description, and the pull request describing the overall work and linking it to the issue ticket.
It will be great to see #5982 addressed, if you can - it's a small bug, but it really affects the usability of the region facet.
#6 Updated by Tim Hutchinson over 8 years ago
Hi Dan - thanks for clarifying that. Subissues was probably the wrong word; good to know there is a way to group the pull requests.
We will definitely want to look at #5982, though we may need some guidance... So let me pester you with another question: if Steve is looking for advice on development/coding, do you want that to happen in the ticket, or is a thread in the user forum or qubit-dev a better way to go?
#7 Updated by Tim Hutchinson about 8 years ago
Hi Dan - We have this just about ready to submit.
I'm just wondering whether you would like the thematic area taxonomy pre-populated with the English terms - similar to repository type.
Our values were based on the CCA's directory of archives: http://www.cdncouncilarchives.ca/directory_adv.html. (It looks like we just changed a couple of the terms.)
I just wanted to check before asking our developer to take this extra step.
#8 Updated by Dan Gillean about 8 years ago
Hi Tim - this is exciting!
Personally, I feel that pre-populating the taxonomy with terms largely derived from the controlled vocabulary that the CCA came up with sounds like a good idea - it will give users a sense of the purpose of the taxonomy in the first place, and if no terms are locked, users can always delete/modify/add terms as they choose.
I am going to forward this issue ticket on to other members of the AtoM team to get some input first, however. More soon.
#9 Updated by Tim Hutchinson about 8 years ago
Hi Dan- Sounds good. Further to this, it looks like all we did was remove Genealogical (which we could add back to the default list) and add Aboriginal Peoples (which I would suggest retaining but it's also easy to remove to be consistent with the current CCA list). It also dawned on me that we could include the French equivalent terms based on the CCA site.
#10 Updated by Dan Gillean about 8 years ago
Adding the translations would be great. So far, everyone who has responded to my thread internally has been in agreement that using these terms would be great. I will wait a bit longer to hear from a few more key folks, but I'm getting the sense that we'd love to see this done.
#19 Updated by Dan Gillean almost 8 years ago
Hi Tim and Steve,
Looks like Jesus forgot to push! Should be fixed very soon :)
Again, thanks for this great contribution. I've tested it locally and found no issues; now that it's merged in our 2x test environment I'm going to do one more pass today before I verify this issue, but it's looking really good.
One small change we may make, that I wanted to let you know about: though we have not achieved consistency everywhere, we have a general habit in AtoM of trying to use sentence case for labels and terms - e.g. Capitalize the first word, and keep the rest lower case. We didn't want to block accepting such an extensive and exciting pull request on something so minimal, especially when there are still a few cases in the application where this hasn't been followed, but in general, we're trying to be consistent about how we label throughout.
So, if we have the time, we may, for example, change the terms included in the Thematic area access point to reflect this - e.g. "Arts and culture" (rather than Arts and Culture), "Industry, manufacturing and commerce" (instead of Industry, Manufacturing and Commerce), etc.
The taxonomy names, I have noticed, are a rather shocking mix of cases - so for now, we can leave Thematic Area and Geographic Subregion as they are (there might even be more using this casing right now than the sentence casing!).
If this is going to impact you negatively, it's not something I feel strong enough about to push at your expense - we'll accept the terms as they are if updating the casing will cause challenges upgrading to the next public release. Just thought I would put the idea out there and see what you think.
Thanks again for this - great work!
#21 Updated by Tim Hutchinson almost 8 years ago
Thanks guys :)
Dan, making the casing more consistent certainly makes sense. I don't see how it would affect the upgrade - I believe Steve has already accounted for the existing taxonomies in our customized 1.3.1 site. So are you wanting us to send another patch to make that so? And in that case when would you need it to make the 2.1 deadline? As you say, there's quite a mix of cases at the moment.
#22 Updated by Dan Gillean almost 8 years ago
No, don't worry about it, Tim - we will try to do that on our end for the 2.1 release. You guys have done great work, and we know you have more AtoM development on the way in the future. We'll figure out how we want to manage the cases here internally, and will do what we can when we can, hopefully in time for 2.1. Thanks again for this!
#23 Updated by Dan Gillean over 7 years ago
- Status changed from QA/Review to Feedback
- Assignee changed from Dan Gillean to Jesús García Crespo
- Tested version 2.1 added
Jesus - i'm getting a white screen when I try to add a geographic subregion access point in qa/2.1.x. I didn't get this previously when testing locally - is it possible its due to the ES 1.3 upgrade merge? We need to figure this out and resolve prior to the release.
#24 Updated by Dan Gillean over 7 years ago
Nginx error log for this:
014/09/05 16:55:53 [error] 853#0: *1706 FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function __get() on a non-object in /home/fiver/Desktop/Projects/atom-2.1/lib/model/om/BaseObject.php on line 505" while reading response header from upstream, client: 127.0.0.1, server: _, request: "POST /index.php/dundas-museum-and-archives/edit HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.atom.sock:", host: "localhost:65535", referrer: "http://localhost:65535/index.php/dundas-museum-and-archives/edit"
#26 Updated by Dan Gillean over 7 years ago
For greater context: it turns out this is a result of the recently-filed but age-old minor bug, #7198. If the user enters data too fast before the slow autocomplete.js finishes, it will throw an error. Had nothing to do with this issue, or with the ES 1.3 upgrade. Sorry for the confusion!