Feature #5596

Repository records - additional access points and facets

Added by Tim Hutchinson over 8 years ago. Updated over 7 years ago.

Status:VerifiedStart date:09/16/2013
Priority:MediumDue date:
Assignee:Dan Gillean% Done:

0%

Category:Repository
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:2.1
Sponsored:No Requires documentation:

Description

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)
This enhancement would add two access points to the ISDIAH record:
  • geographic subregion (e.g., Southwestern Saskatchewan, Northern Saskatchewan)
  • thematic area (e.g., Agriculture, Local/regional history, Aboriginal peoples)
and add facets to the repository browse:
  • 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:
http://sain.scaa.sk.ca/collections/index.php/;repository/browse

Related issue: Improve facet usability - #5278


Related issues

Related to Access to Memory (AtoM) - Feature #3903: Repository records - add browse by certain access points Verified
Related to AtoM Wishlist - Feature #5278: Allow users to see further facet results - improve facet ... New 06/25/2013

History

#1 Updated by Dan Gillean over 8 years ago

  • Description updated (diff)
  • Category set to Repository

(fix links in description)

#2 Updated by Tim Hutchinson over 8 years ago

See also related bug, #5982 - relevant to addition of locality facet.

#3 Updated by Dan Gillean over 8 years ago

  • Assignee set to Jesús García Crespo
  • Target version set to Release 2.1.0

#4 Updated by Tim Hutchinson over 8 years ago

Hi Dan,
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.

Thanks!

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

#11 Updated by Tim Hutchinson about 8 years ago

Hi Dan - Hope I'm not pestering, but I just wanted to check whether you know yet whether we should go ahead with adding the default thematic area terms. Thanks!

#12 Updated by Dan Gillean about 8 years ago

Hi Tim,

So far everyone here is in agreement. If you have the developer time to do it, please do add the terms! Thanks again for checking in with us, and for your patience - we're looking forward to seeing this feature in AtoM!

#13 Updated by Tim Hutchinson about 8 years ago

Thanks, Dan. Hopefully we'll get this one done on time for 2.1.

#14 Updated by Dan Gillean almost 8 years ago

Just saw the pull request - exciting!!!

https://github.com/artefactual/atom/pull/31

#15 Updated by Tim Hutchinson almost 8 years ago

You beat me to it :)

#16 Updated by Jesús García Crespo almost 8 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Jesús García Crespo to Dan Gillean

Merged. Excellent quality!

#17 Updated by Tim Hutchinson almost 8 years ago

Thanks!

#18 Updated by Tim Hutchinson almost 8 years ago

So does your local repository just take a while to sync? I can't seem to find this in qa/2.1.x.

#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!

#20 Updated by Jesús García Crespo almost 8 years ago

oh oh git push :) what was that for again? haha I can tell when I'm doing things at 6pm vs 9am.
done now.

#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" 

#25 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Feedback to Verified
  • Assignee changed from Jesús García Crespo to Dan Gillean

Dan and I realized that was a false alarm. All good. Thanks.

#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!

#27 Updated by Tim Hutchinson over 7 years ago

Whew :)

Also available in: Atom PDF