-
Notifications
You must be signed in to change notification settings - Fork 2
Backlog Grooming Notes
Some items from the last few Backlog Grooming sessions:
The Blacklight OAI gem epic [1] is on hold pending completion of DRY Nyucore <--> controller stories [2-3].
We want to iterate on the web archive story, this time targeting a website with ample Dublin Core fields, e.g., something from the Tamiment collection that was fully cataloged [4]. "Anarchism", for example, has a good metadata-rich collection record [5]. Not sure about the seed [URL-level] records. At some point, we'd also like to revisit the Composer web sites, but we'll need to find a way to process non-DC metadata from the WARC or WAT files. Carol has monthly meetings that includes Jefferson Bailey so she can ask him to advise on latest recommended practices.
Regarding Wojnarowicz, ACM confirmed that current DMD capture and display in BobCat Dev is good enough to present to Special Collections. Carol will arrange a meeting with them to which all Ichabodians will be invited and people can self-select via RSVP. While not a prerequisite of the meeting, Daniel mentioned that call number could be mapped to Dublin Core "Source" element [6], but PNX mapping may be trickier. Also, this will be an opportunity to try out our new workflow for adding fields to Nyucore.
Based on inquiry from Data Services (via Mike Haag), we created a user story for enriching Metalib records before exporting to Primo [7]. (In a separate conversation, Reed suggested that many of the 1,500 Metalib information resource descriptions (IRDs) may have full record counterparts in WorldCat, so we need to check there first before considering enrichment. )
Regarding South Asian NGO reports, we reminded ourselves that the reason Mike can't re-sequence publisher name, publisher date, and publisher collection (per Aruna's request, [8]) is that they're being captured in unqualified DC in the current FDA. Once the DSpace upgrade is complete, we will have the option to use the more nuanced DC-Terms, which will also help with the previous issue of "date" types. Incidentally, Aruna stopped by KARMS to thank us for the team's work and to emphasize the value of capturing subject headings through Ichabod (which we already do, actually) and to export records to WorldCat (which we don't).
We may want to ask Reed to take on ISAW Flickr story. Not sure we ever resolved issue reported by David of Flickr API data exchange throttling.
We noted that archives discovery portal work will resume in the summer. Still open question whether, post FAB, it will continue to use Blacklight or switch to ArchiveSpace (which is developing its own attractive UI courtesy of Yale). There's interest in building a Findings Aids portal API that Ichabod and other apps can work with once ACM signs off on the new platform.
We still want to change Nyucore application profile to re-use terms from external ontologies, possibly from BIBFRAME Lite [9].
[1] https://www.pivotaltracker.com/epic/show/2181230
[2] https://www.pivotaltracker.com/story/show/113562183
[3] https://www.pivotaltracker.com/story/show/113569497
[4] https://www.pivotaltracker.com/story/show/116615885
[5] https://partner.archive-it.org/seam/resource/collectionFeed?accountId=567&collectionId=6335
[6] https://www.pivotaltracker.com/story/show/117062979
[7] https://www.pivotaltracker.com/story/show/116361615
[8] https://www.pivotaltracker.com/story/show/106640866
Present: Daniel, Esha, Carol
Daniel mentioned that he, Corey, Reed, and Mike met yesterday to review options for the remaining (i.e., not yet mapped) Nyucore fields to external vocabularies (e.g., BIBFRAME), and the relationship of Nyucore vocabulary to the new metadata_fields.yml file as well as nyucore_datastream, and app/models/nyucore.rb. This mapping work should help when adding new collections to Ichabod, or when exporting Ichabod content to external aggregators.
We queued up stories around OAI for next week's Sprint Planning.
We closed (and retroactively pointed) an old story about Nyucore, which referred to the planning work before and during the recent hackfest.
We talked about archival objects from the Wojnarovicz collection, e.g., images of his art works, and what it means for them to be presented independently of their original contexts. Daniel had received feedback from Collections Steering questioning the value of objects presented in this way. still, we want to get the mapping finished from FAB to Ichabod to Primo Dev, so we can at least evaluate the work that's been done so far and consider use cases from various perspectives (e.g., both both archivists and art historians).
Present: Daniel, Carol
We noted that we have a product discussion session scheduled for 11/17, 12-2pm, in the DLTS conference room: "Agenda: an informal discussion of Ichabod-as-a-product, where it's going, where we want it to go. Lunch will be served."
We are setting up a meeting with project sponsors for some time after that. The sponsors, you may recall, were Michael Stoller, Roddy Austin, David Millman, and Marty Kurth. Now that Marty's gone, Daniel and Nina S. will need to fill in. We want to use this meeting to make sure we're still in alignment with the Library's strategic goals, check in on getting the Hydra CLA signed, and consult with Michael Stoller on the relationship between Ichabod and the new Strategic Initiative 4.5: "Develop a plan to collect and provide appropriate access to free electronic resources that may require local storage or repository infrastructure, including materials from the internet and other sources and purchased materials in 'born-digital' format that are not presently supported for the general collections."
Based on some additional feedback from Aruna, we modified or added chores regarding the South Asian NGO Reports. At least one issue seems to be an FDA input error, i.e., inserting the original server URL into the dc.identifier.citation field. According to the relevant DCMI spec (or proposed spec [0]), it seems this field should contain a bibliographic citation.
Two of Aruna's issues are specific to Primo rather than Ichabod, i.e., the current ordering of imprint elements [1] and mapping of "Citation" to "Related Titles: Series:" in BobCat. [1.5]. Question: should this instead be mapped to "addinfolink" in PNX? Is there something more specific that can represent "the object as found in its original location", i.e., before it was copied and stored in the FDA?
We discussed whether an additional Ichabod tech meeting would help move the OAI story [2] forward. Corey reminded us afterward in scrum that there's already a breakdown of OAI tasks from the last Tech meeting, and these could be turned into new subordinate user stories.
We added a new story for web archives, this time focusing on the Tamiment collection that often includes rich DMD [3]
We noted progress being made in stories for gis data sets [4], NYU Press Open Access books [5] and AWOL [6]. (And Tom agreed to provide field mappings between AWOL in Nyucore, but we need to remind him.)
[0] http://dublincore.org/usage/meetings/2002/05/citproposal.html
[1] https://www.pivotaltracker.com/story/show/106640866
[1.5] https://www.pivotaltracker.com/story/show/106640724
[2] https://www.pivotaltracker.com/story/show/80775522
[3] https://www.pivotaltracker.com/story/show/107401726
[4] https://www.pivotaltracker.com/story/show/91601928
[5] https://www.pivotaltracker.com/story/show/106210416
[6] https://www.pivotaltracker.com/story/show/91605710
Present: Daniel, Esha, Carol
Daniel will invite Reed to join sprint planning and scrum meetings, with the understanding that OCLC Reclamation may delay active participation.
Daniel will review crosswalk from geospatial metadata elements [1] to Nyucore [2]
The Masses source reader is to be reactivated [3], with designation as WIP (work in progress).
Kate appears to be finished with the Indian Ocean Postcards story [4]. Ready to load postcard metadata into Ichabod.
Daniel will "accept" completed chore for DPLA export criteria [1] and remove references to WorldCat and HathiTrust
Carol will talk with Tom Elliot about issues with the AWOL Index data [6]. Why is he escaping certain Unicode characters in his JSON output? Is he OK with Ichabod ingesting only records that include "subordinate resource" fields but not any "is part of" fields?
Regarding Arabic Collections [7]: We can harvest Solr JSON data through Drupal, but it's lossy compared to the MARC data that's on GitHub. Consider trade-off between using Ichabod as an aggregation hub vs. loading into Aleph when MARC is available. What are the implications for long-term metadata management and sustainable workflows?
[1] https://www.pivotaltracker.com/story/show/91601928
[2] Column F in https://docs.google.com/spreadsheets/d/1nzXtEP0DC2izJDIuGvLWYwSMqWaiX0hBanz6w4znfYg/edit#gid=1090730621
[3] https://www.pivotaltracker.com/story/show/105666520
[4] https://www.pivotaltracker.com/story/show/88356576
[5] https://www.pivotaltracker.com/story/show/97205392
[6] https://www.pivotaltracker.com/story/show/91605710
[7] https://www.pivotaltracker.com/story/show/105109572
Daniel will speak with April Hathcock about boilerplate copyright statement for digital media: Masses, Rosie, NYU Press, Wojnorowicz, HIDVL, which, like thumbnail images, and link to resource, is a requirement for DPLA mapping.
He'll also be meeting with Don Mennerich about additional user stories (and possible harvesting techniques) for Web site archives (given the scant DMD available for the Comoposers Websites collections).
We need closure on the FAB mapping story [1]
[1] https://www.pivotaltracker.com/story/show/99610988
Present: Daniel, Corey, Flannon, Carol
We spent the whole meeting discussing infrastructure ideas with Flannon.
Present: Daniel, Esha, Carol
The chore [1] of mapping Nyucore to MODS is largely done [2]. In order to conform more fully to ESDN requirements [3], Daniel reviewed or added 3 elements in the mapping table along with their DPLA label, DPLA property, and MODS Elements:
-
"Is Shown At" (i.e., backlink to original repository record)
-
" Preview" (i.e., thumbnail image URL)
-
"Provider"
See mapping table for details [3].
Daniel suggested that "Is Shown At" be mapped to Nyucore "citation"; and that we add new Nyucore elements for (1.) "Preview" (i.e., thumbnail image) and (2.) "Data provider" (for which the value in Ichabod will presumably always be "NYU").
We were awaiting feedback from Sally and Chela about the FAB harvest user story [4], though we may have enough information in Corey's draft mapping.
There's a new programmer in DLTS named David Arjanic who may be able to join the Ichabod project.
We should consider planning a sprint with support from Data Curation Experts [5]. One possibility would be to help us migrate to Fedora 4, though reported F4 performance bottlenecks might argue for holding off for a while. Others ideas include items from the Ichabod Futures wishlist. Daniel will explore possible funding options with Cabinet.
Daniel and Carol have reached out to SocHum, IFA, and ISAW, to schedule site visits and demonstrate Ichabod functionality, collect more user stories, and in general find out whether Ichabod is helping (or can help) them meet their users' needs.
Work is proceeding on Indian Oceans Postcard user stories [6], [7]
Daniel will give a brief update on Ichabod at an E-Access Brown Bag event on Friday.
[1] https://www.pivotaltracker.com/story/show/97205392
[3] http://empirestate.digital/contributors/metadata-requirements/
[4] https://www.pivotaltracker.com/story/show/99610988
[5] http://curationexperts.com/
[6] https://www.pivotaltracker.com/story/show/95535238
[7] https://www.pivotaltracker.com/story/show/88356576
Present: Daniel, Carol, Esha
We discussed the update to Ichabod Dev with Hannan's "login-integration" branch [1],[2], but it turns out that the new log-in functionality is not ready, so needs to be rolled back.
We discussed tests failing on Travis [3] when loading records from The Masses. We decided to keep Masses out of Ichabod for the moment. However, we are committed to understanding and solving the problem so that the Masses story can be finished and so we have confidence in our infrastructure. Esha is reaching out to Barnaby for additional input. Daniel and Carol mentioned having Web Services re-engage with Ichabod, since they have more access to the full Ichabod stack, and they were planning to come back anyway.
The Indian Ocean ingest is on hold pending resolution of the Travis issue.
We talked about OAI dissemination for Primo and for DPLA. Corey has pointed out that WGBH OAI gem is missing important functionality, and he has some ideas about building an OAI disseminator from scratch. We can revisit this in sprint planning.
Carol did some research on exporting ichabod data to HathiTrust, DPLA, and WorldCat [4]. Daniel offered to take the next steps. [He and Corey have been looking at some of the pre-requisites for DPLA, via submission to ESDN]. Related to this is a chore to map Nyucore elements to Dublin Core, MARC, JSON-LD, etc. [5]
Daniel had asked ISAW's Jill Golden for her mapping of Flickr [6] fields to Nyucore, but it was too late, as Jill had already left NYU for another position. He is following up with David Ratzan.
Daniel will continue to attend backlog grooming during his Goddard leave, but Corey offered to stand in if he can't be there.
In case people stumble upon Ichabod unintentionally, we modified and scheduled a chore to have an "About" link embedded into the Ichabod home page [7].
We scheduled a chore to change (Aruna's) PDFs resource type from "Technical reports" to "Reports" [8]. The latter is less misleading for what we currently have, but we'll still need a controlled list of resource types at some point [9].
Discovery that Ichabod Prod was down made us realize we need better Nagios monitoring [10]
There's a chore to review the Nyucore element set through a catalogers eyes [11], to ensure consistency with BobCat and basic cataloging principles. This may be related to the "resource type" question above.
[1] https://www.pivotaltracker.com/story/show/99134430
[2] https://github.com/NYULibraries/ichabod/tree/feature/login-integration
[3] https://www.pivotaltracker.com/story/show/96673142
[4] https://www.pivotaltracker.com/story/show/97205392
[5]https://www.pivotaltracker.com/story/show/97204750
[6] https://www.pivotaltracker.com/story/show/91605860
[7] https://www.pivotaltracker.com/story/show/97769492
[8] https://www.pivotaltracker.com/story/show/97760200
[9] E.g., building on http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements#H7, http://metadataregistry.org/concept/list/vocabulary_id/46.html, http://metadataregistry.org/concept/list/vocabulary_id/37.html, http://metadataregistry.org/conceptprop/list/concept_id/529.html
[10] https://www.pivotaltracker.com/story/show/99133930
[11] Rhttps://www.pivotaltracker.com/story/show/97201160
Today's meeting was canceled. Here's a retrospective summary from June, in lieu of detailed notes:
Even though Ichabod isn't an official NYU public interface, the site is open-access and people might stumble upon it. For that reason, Daniel drafted this FAQ [1]. We now need a chore to get it embedded in the site.
We decided (tentatively) that the absence of an IP rights statement in Ichabod implies a resource is open-access. Also, that "title" as well as "discoverability" (inherited from the "collection" object) should be required fields. But should these be the only required fields? We want to confer with KADD on minimum requirements for geospatial resource discovery in BobCat, e.g., presence and granularity of subjects, coordinates, spatial location. We noted that geospatial DMD needs more specificity on the meaning of "date issued". We decided that the group would benefit from a meeting about Ichabod architecture, including methods for adding new fields to NYU core. (It appears this meeting took place on June 25th.) We noted that there are problems currently with Research Guides tests and with Travis. We want to have Heidi review Nyucore fields from cataloger's perspective [3]. We're interested in enabling JSON endpoints for Drupal sites beyond just Rosie and Beard. Since Ichabod's not an official UI, we decided "consistent display of fields" [3] is non-urgent, and placed it in Icebox. Stories about HIDVL, batch delete/load Jenkins jobs [4], and forced-choice drop-down menus [5], were moved from the Icebox into the Backlog.
Regarding Web archives, we are still awaiting delivery of WAT datasets [6] from Archive.org, and we still need Kent (or his delegates) to enrich the metadata in Archive-It, but in the mean time, Daniel's wondering [7] if we could use the API queries built into the Archive.org advanced search [8] to capture persistent URIs and more of the fields that are already there. The thing is, it seems the "number of results" parameter is being capped at 10.
[1] https://www.pivotaltracker.com/story/show/97769492
[2] https://www.pivotaltracker.com/story/show/97201160
[3] https://www.pivotaltracker.com/story/show/73889788
[4] https://www.pivotaltracker.com/story/show/93928290
[5] https://www.pivotaltracker.com/story/show/97285264
[6] https://webarchive.jira.com/wiki/display/ARS/WAT+Overview+and+Technical+Details
[7] https://www.pivotaltracker.com/story/show/98645612
Present: Daniel, Carol, Esha, Kate, Corey
We started off talking about Open Repositories [1], e.g., getting the Ichabod presentation notes and slides in order before the conference starts on June 8th.
We spent most of the remainder of the meeting on a new epic [2], namely: "As other systems, I want to be able to receive data from Ichabod, so that I can make the data available to more users." We associated this epic with the tag "export". If you click on that tag, you'll see 7 user stories: 6 features and 1 chore. Thinking of this as an epic can help us produce a coherent strategy for our various export needs, e.g., MODS for the Indian Ocean postcards [3], MARC for HathiTrust via Zephyr [4]. OAI-PMH for Primo [5], etc. We agreed that a good first step in this epic is to set up the OAI endpoint in Ichabod [5].
I neglected to post notes from the previous week's meeting, i.e., 5/21. We also started that meeting with an update on Open Repositories planning. We then re-ordered, added, and edited stories in preparation for the next day's Sprint Planning.
[1] http://www.or2015.net/open-to-all/
[2] https://www.pivotaltracker.com/epic/show/1875134
[3] https://www.pivotaltracker.com/story/show/95535238
[4] https://www.pivotaltracker.com/story/show/95533474
[5] https://www.pivotaltracker.com/story/show/80775522
Present: Daniel, Esha, Carol
We discussed changing the Wednesday scrum time from 1pm to 11am, effective 5/20/15.
We reviewed slides in advance of Hydra New England Meeting, which Kate, Esha, Daniel, Carol, and Laura Henze are attending tomorrow.
We reviewed the outline of a presentation for Open Repositories, which Carol, Kate and Daniel will be attending June 8-11.
We created an epic (with 5 stories thus far) on entering HIDVL metadata into Ichabod [1]
[1] https://www.pivotaltracker.com/epic/show/1836448
Present: Daniel, Esha
We moved some stories from the icebox to the backlog, including one about keeping data-sources in Ichabod up-to-date [1]; adding a collection field for "Research Guides" [2]; adding collection metadata for ISAW images from Flickr [3], AWOL posts from Zotero [4], and integrating spreadsheet metadata for Indian Ocean postcards [5]
Daniel mentioned that Web Services may not be able to rejoin Ichabod sprints in the short term, since they're still preoccupied with web presence redesign and the single-sign-on system and other stuff. Not sure if that's a problem for now, since between DLTS and KADD we're able to continue working on new user stories for metadata modeling, added collections, and Primo ingest. We should feel free (per Roddy) to consult with Barnaby and Hannan as needed for assistance with Jenkins, etc. We do need to re-visit and document our long-term strategy and priorities for Ichabod, now that the Strategic Initiative 4.3 is arguably finished, so that we can stay mindful of what we're building and its relative importance vis-a-vis other projects.
Daniel mentioned his participation in a separate meeting on the status of web archives curation at NYU. Other attendees were Chela Weber, Don Mennerich, Janet Bunde, Tim Johnson, Kent Underwood. New user stories for web archives discovery are on hold, since NYU is in the process of migrating its Tamiment Web archives from CDL to ArchiveIT. As they review CDL files, Don and Chela are discovering issues with subscription costs and quality assurance. It turns out that out that Tamiment has 1589 seeds in CDL, and there is a need for enhanced standardization and appraisal. There's talk of a new library-wide strategic initiative dedicated to this effort.
Also at this meeting we discussed the ArchiveIt Research Service [6] and in particular, the possible use of WAT and WANE files. WAT (Web Archive Transformation) files "feature key metadata elements that represent every crawled resource in a collection and are derived from a collection's (W)ARC files." WANE (Web Archive Named Entities) files "contain a list of all of the people, places, and organizations in every text document of a collection, along with the timestamp of capture, and are derived from a collection's (W)ARC files." We're still interested in processing WARC files directly in Ichabod and doing our own entity recognition and extraction, but it will be interesting to see what sort of results come out of the WANE files. It's a paid service, so Daniel requested a quote from the Internet Archive. Since we're just experimenting, though, maybe we can get a free trial. We might start with archived NYU Course Bulletins [7], proposed by Janet Bunde, since it's a public access collection and includes DACS [8] metadata. Another suggestion was the web archiving work being done by students in the Moving Image Archive Program (MIAP) [9], though it's not part of the library account, and doesn't have much DMD. Aruna seems to be involved in this project, and Daniel can follow up with her.
Another collection of possible interest to Ichabod is Indigenous Media Online (IMO) [10]. Despite the title, though, the items are not actually online. It's a collection of analog film and video being transferred from the Smithsonian to NYU. It's the catalog and web site that's online. Since the resources are not digital format (yet), it's not quite within scope for Ichabod. A meeting is scheduled with Daniel, Angela Carreno, Carol, Alberto, and Esha, to discuss harvesting selected metadata, and possibly housing or rebuilding the full website since it includes more than just bibliographic data.
[1] https://www.pivotaltracker.com/story/show/91605190
[2] https://www.pivotaltracker.com/story/show/91605284
[3] https://www.pivotaltracker.com/story/show/91605860
[4] https://www.pivotaltracker.com/story/show/91605710
[5] https://www.pivotaltracker.com/story/show/88356576
[6] https://webarchive.jira.com/wiki/display/ARS/Archive-It+Research+Services
[7] https://archive.org/details/ArchiveIt-Collection-4517
[8] http://files.archivists.org/pubs/DACS2E-2013.pdf
[9] http://www.nyu.edu/tisch/preservation/
[10] http://filmcatalog.nmai.si.edu/intro/
Present: Daniel and Mike Haag (at KARMS), Esha and Corey (on Hangout); Carol was out sick
We talked about the desired Collection object [1], and that our immediate need is something that can control collection name properties across all records in Ichabod. We added a task "Ensure that collection objects aren't solrized on persist to Fedora". Something to consider down the road is whether we want things like Collections to have their own landing (or "identity") pages, in the way we have now for manifestations (a.k.a. resource titles).
We talked briefly about the two proposed ISAW user stories: a Zotero collection [2] and Flickr stream [3]. We're not sure if these are ready to be assigned in Sprint Planning, but it would be good to get input from the group.
We talked about tasks associated with moving the Ichabod-Primo pipe into production. Having both Mike and Corey on the call was a good opportunity to revisit the list of UX issues and see how the remaining work can be shared and/or divided up. Corey put together a helpful list. Some of the chores still need to be captured in PivotalTracker.
[1] https://www.pivotaltracker.com/story/show/91605284
[2] https://www.pivotaltracker.com/story/show/91605710
[3] https://www.pivotaltracker.com/story/show/91605860
Present: Daniel, Esha, Carol.
We drafted a new user story for getting more data out of the SDR and into Ichabod [1]. This is partly in response to certain colleagues' interest in GeoBlacklight, which we're not in a position to stand up now, but we can add DMD fields and use some of the workflow elements (e.g., the GeoBlacklight stylesheet) from that project.
We're in a holding pattern with Ichabod-to-Primo in production (see notes from previous meeting, below)
We're still interested in automating scheduled data source ETL via Jenkins (e.g., [2])
We're still interested in implementing the 'Collection' object, which has a dependency on larger data modeling considerations. In the mean time, though, we want to assign a collection name to the set of NYU Research Guides [3]
Daniel mentioned two user stories recently proposed by David Ratzan and Tom Elliot of ISAW.
- The first [4] involves blog posts from Ancient World On-Line (AWOL), metadata from which have been extracted and ingested into a Zotero collection. These entries describe open-access items that in some cases already have records in Aleph. We would either need to filter out the redundant records or rely on common match-points and Primo's dedup/mrg algorithm. The nice thing about the second option is that we could augment traditional cataloging with curator annotations from the AWOL posts.
- The second proposed user story [5] is an ISAW image collection. They have 3,000 open access images exposed through Flickr, with 800-900 more in the queue. They mentioned some interest in using Omeka or the FDA for additional dissemination, but perhaps straight-to-Ichabod is another option. One neat thing about this image collection is that it's enriched with linked-data-friendly identifiers from Pleiades [6] and Pelagios [7].
Now that she's been through Hydra Camp, we'd like to start inviting Heidi to sprint planning. Daniel will discuss with her.
Some DLTS members will be attending the NE Regional Hydra meeting at Brown on May 7 [8]. Daniel is considering. Anyone else from KADD? Anyone from WebDev?
We drafted a Hydra Partner letter of intent and shared it with Millman and Marty. They are discussing it with the Dean.
Our proposal to speak at the Open Repositories conference in Indianapolis [9] was accepted. The dates are June 8-11.
[1] https://www.pivotaltracker.com/story/show/91601928
[2] https://www.pivotaltracker.com/story/show/71320818
[3] https://www.pivotaltracker.com/story/show/91605284
[4] https://www.pivotaltracker.com/story/show/91605710
[5] https://www.pivotaltracker.com/story/show/91605860
[7] http://pelagios-project.blogspot.com/p/about-pelagios.html
[8] https://wiki.duraspace.org/x/yAUCB
Present: Daniel and Carol
Temporary slow-down in Ichabod is OK. There’s a lot going on with the Finding Aids portal, etc.
Once scrum sessions are back on track, we can revisit issues surfaced at the 1/28/15 UX meeting [1]. e.g.,
-
“Fix the Primo ingest so that only ESRI collection materials say "NYU Only" and the others are marked as publicly available.” https://www.pivotaltracker.com/story/show/89614570
-
“Explicitly map Ichabod resource types to Primo resource types” https://www.pivotaltracker.com/story/show/87111758
-
“Change Primo normalization rules so that "Additional Links" contain the right URL (for ESRI, it's the download instructions.)” https://www.pivotaltracker.com/story/show/89614728
-
“Change resource type for NYU Press Open Access Books from "Text" to "Book.”” https://www.pivotaltracker.com/story/show/89615484
Daniel will be setting up meeting on Web archive harvesting with Carol, Kent, Tim Johnson, Don Mennerich, and anyone Don wants to bring with him. E.g., ingesting WARC files in their entirety. Need to send message about what's appearing in production. Need to get list of whom should be notified when new collection is added to production.
New website for Indian Ocean books rolled out today [2]. PivotalTracker Icebox includes new story on discovery of Indian ocean postcards [3]. Ingestion in Ichabod could be happening in parallel [with digitization?]. Right now metadata is recorded in spreadsheet. We want a data loader to be able to import data in this kind of format. Kate is working on semi-generic CSV data loader.
[1] https://github.com/NYULibraries/ichabod/wiki/Backlog-Grooming-Notes#12815 [2] http://dlib.nyu.edu/indianocean/?page=1 [3] https://www.pivotaltracker.com/story/show/88356576
This meeting was dedicated to UX issues. In attendance were Daniel, Carol K., Corey, Barnaby, Nadaleen and Laura Henze.
We started by looking at the LION geospatial data resource (from New York City Dept. of City Planning) in BobCat Dev, originally cataloged in the SDR. Nadaleen noticed the format type "geospatial data" (without icon), asked about the breakdown between geographic data and numeric data types, and whether it would be possible to have a more hierarchical display of resource types. This is not an option in Primo, but may be an option in Blacklight e.g., if Ichabod were treated as its own discovery portal.
We noticed that "geospatial data" was not showing up in facets under "Resource Type." Corey explained that this was due to Primo using static types, and that he can help Mike update the appropriate mapping tables so that all Ichabod types are successfully mapped to Primo.
Daniel agreed to prepare a document defining resource type in Ichabod and distinguishing it from "genres", or other, related data elements.
Daniel expressed concern about getting the format facets grouped and labeled properly. Nadaleen pointed out that only something like 0.1% of BobCat users actually click on facets. We don't know, though, how much this has to do with facets per se and how much has to do with our local implementation.
Clicking through the details page for LION, all were glad to see that clicking the "Available Online" link correctly triggered a download of the actual data set. It required authentication, though. We think Magellan is behind a firewall and is supposed to work through EZ Proxy. We think only ESRI data should require authentication (BWEB) and the rest should be open access (WEB). Do we need further discussion with Himanshu?
There was a question about "Additional Links," which currently opens a blank page, but is supposed to open the download Instructions page. We'll need to ask Mike to look into this and revise the Primo norm rules to capture the appropriate URL.
Someone asked if we could change the "Available Online" label in BobCat to "download" as it appears in Ichabod. And if we should include the file name in the link text and the file size in parentheses, after the link. We decided that this should be a user story in Ichabod first, which could then be inherited by BobCat downstream. Also, we need to review cases in which the current BobCat label should just be "Available Online" without the indication that it's only for NYU patrons. It seems this can be managed by assigning restricted resources to BWEB and other resources to WEB.
Looking at Ichabod, we noticed that NYU Press open access books are receiving the format type "text" rather than "book", for example, for "Genders 22" (1995) and the "text" label is carrying over into BobCat. The discrepancy should be captured in a user story. We also noted the incorrect indicator of "(NYU access only)".
We should add criteria to NYU Press open access books user story to include all metadata including ISBN and abstracts.
We discussed whether patrons should be able to click through from BobCat back to Ichabod, or do we need more vetting of the Ichabod UI first.
And we asked ourselves if we need a chore to get more icons created for new resource types.
It was just Carol and Daniel this time.
We reminded ourselves to hold off on the generic loader story [0] until we have a discussion led by Kate (cf. [1]).
We noted that Ichabod and BobCat Dev are out of sync. Mike's Nov. 13 JSON ingest was a one-off, and more collections have been added to Ichabod since then. Daniel offered to follow up with Mike about a new JSON ingest, and also to follow up with him and Corey about setting up the Blacklight OAI endpoint [2]. (NOTE: When Daniel later asked Mike about level-of-effort involved, Mike replied that the bottleneck was having to page through maximum 100 JSON results at a time. So then, at Sprint Planning, Daniel asked if we could bump up the maximum number of retrieved records per page to 2,000. After some discussion, a consensus emerged that while technically feasible, it’s probably not wise since the default limit is a throttle that safeguards performance and system stability.)
We considered if either of Allen Jones's user stories [3] are worth reviewing at this point. They involve metadata enrichment, however, for which we don't yet have a workflow, so better to wait for more discussion on Ichabod architecture and long-term strategy.
Things are slowing down as we approach the end of the year, and also because some of us are working simultaneously on Finding Aid Portal user stories. So we don't expect a lot of new development in December. We did create a few stories on adding new collections, though, on the assumption that they’re fairly straightforward.
We looked at some Rosie the Riveter data in Ichabod and noticed that there's not much detail there to identify the resource (e.g., search on "Jerre Kalbas"; the full view includes just title and handle). Curators have requested the first 80 characters of a summary note, along with the name of the collection. These fields are being indexed and displayed in BobCat Dev, so they are being passed through Ichabod. Also, we noted that the original records include thumbnail images [4], so we decided to add a user story to carry those images in to Ichabod [5].
We noted that this Thursday would be last sprint planning session of the month.
[0] https://www.pivotaltracker.com/story/show/82229020
[1] https://www.pivotaltracker.com/story/show/83955024
[2] https://www.pivotaltracker.com/story/show/80775522
[3] https://www.pivotaltracker.com/epic/show/1503074
[4] http://dlib.nyu.edu/rosie/interviews
[5] https://www.pivotaltracker.com/story/show/83851656
This is a combined summary of notes from the past few weeks.
We've had multiple discussions about the future direction of Ichabod prompted by the recent All Staff table topic discussion, the drafting of a report on the Strat 43 initiative, and the fact that our scrum master, Scot, has left NYU (except for some consulting work).
With Scot gone, Barnaby stepped in as scrum master. This could only be temporary, though, since he needs to focus his efforts (for now) on other strategic initiatives such as the library website redesign and the new special collections discovery portal. So Esha volunteered to take on this role moving forward. In addition to leading scrums and sprints, she will meet weekly with Daniel and Carol to review user stories and help develop acceptance criteria.
We extended an open invitation to Corey to attend this as well, given the need for more strategic thinking around NYU-Core implementation. For example, Corey wrote on the PR 103 comment thread [2], " Related to the "collection" conversation we had the other day, RDF would want us to think of the "value" of language as a complex object rather than a literal value. Then it can have a URI, a preferred label, an ISO label, and other possible properties ...." He also recommended that we "start preserving our "sourceResource" as part of the resource set parsing process. This doesn't need to be as a metadata datastream, but perhaps we could capture it as a binary datastream. This way, we can stuff the original data in there whatever the format: json from an api, xml, csv, rdf, marc, mods, solr, etc." We want to make sure to capture these insights and suggestions, and work them into our user stories.
We've also discussed the review of pull requests, since Barnaby is currently unavailable for that role. We can distribute this responsibility more broadly among Ichabod developers. I believe Joe volunteered, though, to take a lead role in ensuring overall integrity of the code base. [Joe: Please correct me if I'm wrong]
We have submitted a new 'collection object' epic to PivotalTracker: "As a curator, I want Ichabod to organize my data into collections, so that I can manage the resources at that level." [3]. This epic supports several user stories, including the need to keep a set of records suppressed during metadata review, the need to assign editing permissions at the collection level, and the need for inheritance from collection descriptions item descriptions (e.g., for collection names and access rights),
[1] https://www.pivotaltracker.com/story/show/80297254
[2] https://github.com/NYULibraries/ichabod/pull/103#issuecomment-63650928
[3] https://www.pivotaltracker.com/epic/show/1528458
11/9/14
Present: Barnaby, Carol, Daniel
This isn't exactly related to backlog grooming, but we talked about the upcoming All-Staff meeting, and about keeping the hand-out to a single page. Probably just bullet points on one side; diagram on the other. For the diagram, we should consider color coding features that have already been realized vs. those projected for the future. Also add a descriptive title to the diagram, and leave off the other illustrations.
We also talked about the fact that Scott's moved on from NYU (except for some limited consulting hours), and that Web Services will need to focus a lot of their time on upgrading website authentication code. They also need to spend time on the new Finding Aids discovery portal and redesigned library website, So their availability for working on Ichabod will be more limited, but Barnaby is willing and able to continue as scrum master. Barnaby noted that Yale is using ArchiveSpace as its discovery portal. Not sure how appealing that option is for NYU.
Carol reminded us that Alberto is working on the Masses user story, Carol finished her authorization workflow chore. Grouper is on hold.
We added a user story to filter Ichabod results by (numeric) datasets [1] and added a stub Epic for Allen Jones' interest in enriching SFX and Aleph data with additional match points to aid dedup/merge in Primo [2]
[1] https://www.pivotaltracker.com/n/projects/1025368/stories/81297478
[2] https://www.pivotaltracker.com/n/projects/1025368/epics/1503074
Present: Barnaby, Carol, Daniel, Scot, Mike H.
With Mike Haag as our special guest, we focused mostly on the "Ichabod collections in Bobcat" user story [1], and options for ingesting Ichabod metadata into Primo. The plan so far is for Mike to retrieve a complete record set (currently n < 2,000) from Ichabod's HTTP JSON response. Mike would want to pay special attention to the fields with "desc_" prefix and "tesim" (?) suffix, i.e., the fields corresponding to NYU Core. In order to capture collection names, he'll also need the "collection" field, which is not (yet?) included in NYU Core.
Over the next four weeks, Mike will experiment with transformation, ingest, and normalization. He'll need to convert Ichabod data into a format that Primo can process (e.g., JSON -> XML/OAI-PMH, perhaps with something like catmandu? [2]).
Carol tried to enter a new user story in for implementing Hydra's OAI PMH endpoint, but PivotalTracker wouldn't save it for some reason. We hope she'll try again later. We had a bit of a debate on whether this would represent wasted effort, since Mike will be working with the JSON output for the time being. We decided that we can leave the story in the backlog, and when someone has the time and inclination, they can take a look and see how much effort is involved. Then, if it turns out to be fast and easy, it might be worth activating the endpoint even if we don't use it right away.
[1] https://www.pivotaltracker.com/story/show/66549904
[2] http://librecat.org/catmandu/2013/06/21/catmandu-cheat-sheet.html
Archive-It automatically extracts metadata such as snapshot date stamps, collection names, and site URLs. Other elements like subject terms and composer names would need to be added by a subject specialist or cataloger. Kent is looking to enrich metadata for his "New York University Archive of Contemporary Composers Websites" [1], and we suggested that he add them directly to Ichabod rather than Archive-It since the Archive-It harvesting API is undocumented and possibly unstable. We haven't yet completed the user story on Grouper-based editing authorization, but we still have the ability to assign permissions to specific groups on specific resource sets, so we can give Kent (or his proxies) permission to edit anything coming from ArchiveIt. We added a chore to this effect [3]. Also, Kate is close to finishing her story on metadata editing through the Ichabod UI [4], so that option should be available soon.
We assigned a new chore to Corey: "Look at NLP [Natural Language Processing] options for cleaning data as it comes into Ichabod and write a report describing the options, along with a recommendation as to which method is best. (2 weeks)" [5]. We're wondering if anything presented at Hydra Connect is worth considering, e.g., Corey's notes mentioned a BPLGeo gem [6], which he describes as similar to his proposed Open Refine workflows. Also, what kind of tools is DPLA (or Europeana) using? And is data refinement integral to Ichabod or is it a service that Ichabod hands off to and receives back from? There's a related user story in the icebox about using NLP on FDA abstracts [7], but we probably need more user stories for other uses of data refinement and NLP.
Regarding the projected need to synchronize certain Ichabod resource sets with WorldCat independently of Aleph, Dawn Lawson has confirmed that NYU has an OCLC digital collection gateway [8] account, and Carol confirmed that this account ("zyuadmin") is linked with DLTS. The Gateway relies on OAI-PMH, so we'd need to consider how to serialize OAI-PMH records out of Ichabod, if we want to go this route.
The "Language" field is being populated inconsistently, depending on resource set. This undermines the usability of that facet/filter, looks bad when presenting Ichabod to sponsors and public services colleagues; it also makes it harder for the Primo Admin to provide single mapping rule from Ichabod to BobCat. We added a user story acceptance criterion to make sure that records with a language field contain a valid ISO code [9]. There's a Hydra or Blacklight gem that can convert the codes to more human-readable text strings, but that can be done later if/as desired. We also considered that some resources are non-linguistic, e.g., visual images, sound recordings, numeric data sets, and so we created new user story in the icebox to accommodate those [10]
We talked about the upcoming All-Staff Meeting (Thursday, November 13th) and that Strategic Initiative 4.3 plus Ichabod will be featured as a table topic. Daniel asked if the Hydra Connect poster would be a good visual aid. Carol thought it might be overly technical for some participants. Daniel's assigned to lead the table discussion, but Carol suggested that she and other Ichabod project members could participate so that we can represent different aspects of the project and make it easier for any of us to pick a different table for the first or second session.
[1] https://www.archive-it.org/collections/4049/
[2] https://www.pivotaltracker.com/story/show/75974276
[3] https://www.pivotaltracker.com/story/show/80295342
[4] https://www.pivotaltracker.com/story/show/73054952
[5] https://www.pivotaltracker.com/story/show/80299798
[6] https://github.com/projecthydra-labs/Bplgeo
[7] https://www.pivotaltracker.com/story/show/67620670
[8] https://oclc.org/digital-gateway.en.html
[9] https://www.pivotaltracker.com/story/show/80297254
[10] https://www.pivotaltracker.com/story/show/80298428
-
Barnaby, Scot, Carol and Daniel discussed the need for a clear statement on Ichabod's goals. This need is reflected in calls for a product workshop, questions Carol and Daniel are receiving from various quarters, and the fact that a Strat Initiative report/recommendation is expected at the end of this calendar year. We think the short term goal should be to get all of Ichabod content piped into Primo, i.e., the BobCat "Books & More" tab. A longer term goal could be to build advanced aggregation, normalization, and remediation functionality directly into the Hydra stack, but at the moment we lean heavily on Primo for normalization, deduping, FRBRizing, etc. Scot reminded us that some normalization can also be handled at the Solr level.
-
Scot mentioned a much simplified BobCat search UI in development for TNS [1], where the number of tabs is reduced, and metadata from SFX (articles) and Metalib (databases) are folded into the Books & More tab. One of the remaining tabs (current "Articles and Databases"?) could be re purposed for EDS.
-
Are we ready to send metadata from Ichabod to Primo? Do we want to use the Solr API or build an Ichabod API? Note that Some Ichabod fields are not indexed in Solr, e.g., the resource download URL and instructions. So if API is from Solr, Mike would need to add such fields in Primo via norm rules.
-
Mike H. will need to develop mapping from Solr into PNX, and resource types need to be explicitly mapped to corresponding fields in BobCat, e.g., geo-spatial data and NGO reports.
-
We need to talk more with Corey and Mike about what, if any, of the old Primo-based Union Digital Catalog norm rules can be re-purposed for Ichabod. We're inviting Mike and Corey to a backlog grooming session in two weeks.
-
We're mindful that one of the down sides of managing norm rules in Primo is the lack of programmatic access (given forced web interface and Oracle restrictions). Eric Nord at Brigham Young University (BYU) has accomplished something interesting in this regard (doing all of his XML normalization in a locally-managed MySQL database, before mapping fields 1:1 to PNX), and we should consult with him at some point.
-
User story about standardizing display fields in Ichabod (assigned to Daniel? [2]) is less urgent if we decide to have primary access through Primo (for now).
-
We still need to do a sprint on authentication and metadata editing (scheduled for Thursday, Oct. 9th.)
-
Esha is pulling AWDL metadata from Aleph. Will that create duplicates in Primo (i.e., Aleph records already piped to Primo to which we're adding same set of records now via Ichabod)? Do we want to remove the pre-existing records from Aleph first? Do we want to just see how they get deduped/merged? Or perhaps, since Dawn Gross is leaving NYU and won't be available for consulting, HIDVL would be a better test case than AWDL. HIDVL is also cataloged in Aleph, through DMD is initially submitted through an old DMD input form.
-
In general, could we do more with MARC metadata in Ichabod? What about a workflow that sends metadata from Aleph to Ichabod for augmentation, and then sends it from there to Primo? Remember that Blacklight was designed specifically with MARC in mind.
-
Daniel will look into ways of exporting to WorldCat independently of Aleph, in cases where Ichabod or Primo becomes a repository of record. Allen Jones mentioned the Digital Collections Gateway where one can automate OAI harvests into WorldCat [3].
[1] http://bobcatdev.library.nyu.edu/primo_library/libweb/action/search.do?vid=NS2
[2] https://www.pivotaltracker.com/story/show/73889788
[3] https://oclc.org/digital-gateway/gettingstarted.en.html
Considering current availability and work pattern of developers, we discussed switching from Scrum to a different type of agile management that maybe counts as "Kanban" [1].This would mean less focus on sprint planning, and more freedom to pick off user stories as project members are available. We would continue to have regular scrum meetings.
Carol mentioned that Alberto is back from Hydra camp and might be able to take on a user story after a few weeks.
We agreed that any story that begins with "As a developer" should be changed from a Feature-type story to a Chore.
Daniel mentioned that Carolina is leaving NYU, so we reassigned her active story to Barnaby and Scot: "As a GIS cataloger I want to be able to log in so that I can create/update/delete metadata for GIS records."[2] We added a new task to add Daniel and Carol as 'GIS catalogers' so they could test and accept the ability to log-in in through this designated role.
We moved two stories from the freezer to the backlog.
We discussed the need for consistent behavior of hyperlinks. E.g., when you click on Rosy the Riveter collection link, should it redirect search within Ichabod, or take you to the collection description page in Drupal? (cf. [3])
Carol volunteered for the Grouper workflow chore
We discussed whether we need a chore for an API document that can be read by a developer. E.g., how to get data out of Ichabod and into Primo. (In addition to the chore for actually implementing the API?)
[1] http://en.wikipedia.org/wiki/Kanban_(development)
[2] https://www.pivotaltracker.com/story/show/70441694
[3] https://www.pivotaltracker.com/story/show/78290270
We're still focused on getting a beta environment set up and adding more collections. We have pretty much the user stories we need for the beta instance (tagged 'beta release', e.g., [2]). For added collections, we defrosted and assigned acceptance criteria for stories on web archives [3] and research guides [4], and confirmed that Kate is still working on the FDA NGO story [5].
Daniel said he still wants to collect more user stories for web archives. We have several good ones in PivotalTracker, but all were all submitted by the Avery Fisher Center. He said he would reach out to Nancy Cricco, Tim Johnson, and Chela Weber, and ask them to review the current stories (tagged "Websites" in PivotalTracker) and submit others if and as needed. [BTW, one thing that becomes more obvious when the Avery Fisher stories are viewed side-by-side, is their desire to have all composer names indexed in Ichabod, but have Ichabod link back only to the collection-level page in archive.org (e.g., [6] and [7]). This adds a certain complexity that needs to be considered by Ichabod developers, namely, as one story suggests: "As a curator of an NYU Library web archive, I want an automated mechanism that will update the BobCat database whenever a new named entity is added to the archive landing page, so that, e.g., a BobCat author search for an added personal name will include the web archive landing page in the search result" [8].]
For the collection stories that we just brought in, we wanted to be sure that sufficient metadata were already available for harvesting, and that we wouldn't need to rely on full text indexing. E.g., is there something there that maps to NYU-Core 'type' or language? In the acceptance criteria, though, we ended up just specifying the the creator name element for websites, and the title element for research guides.
Daniel expressed his concern about consistent application of value vocabularies for the 'type' element, and wondered if we should be using registered terms from the Open Metadata Registry. [He was thinking about the linked data RDA vocabularies for content, media, and carrier [9,10,11] but perhaps DCMI 'type' values [12] are granular enough?]
We discussed our assumption (i.e,. as our 'minimum viable product') that Ichabod's contents will be piped into the Books and More tab. But Scot mentioned recent a Finding Aids Portal user story from Chela, namely, "I want to limit to digital format so I can work from home," and we recognize that this is hard to achieve in Primo, i.e., our current Books & More tab. So here's a compelling case for a dedicated discovery portal for digital collections, especially if it allows us to assign multiple types to individual resources, e.g., 'digital object' and 'finding aid', and avoids the dedup/merging that can interfere with filtering and faceting by type. Carol mentioned that there is already an issue in Primo with AWDL digital texts conflating with their physical counterparts, and not being discoverable by type. Scot mentioned that Allen is trying to avoid a similar problem with MARCit by assigning SFX e-journals a unique resource type. Ichabod does not impose a single resource type (and does not apply dedud/merge) so one could assign as many terms as needed.
We agreed that we still want to hold an "Ichabod Product Workshop", but it needs to be rescheduled.
Carol mentioned that AWDL is currently managed in Aleph, and might better be managed in Ichabod (for reasons mentioned above, i.e,. to avoid mutually exclusive type assignment and dedup/merge as it gets piped into Primo).
That raised the question of why and when KARMS considers Aleph the metadata repository of choice. Daniel suggested three main criteria:
-
Authority control (e.g., for consistency of access points and thesaural browsing)
-
Inventory control (e.g., for status-tracking physical items)
-
Fiscal control (e.g., for submitting orders, managing budgets, tracking invoices)
How do these roles relate to Ichabod? Aleph is currently our best bet for authority control. In the long term, though, we we need something scalable across multiple repositories. [And work's being done in the Hydra community to support a broader solution, e.g., the "Question Authority" Ruby gem [13].) Aleph Inventory control is primarily used for physical collections, so most likely not a factor for digital collections in Ichabod. I doubt we'd want or need to reproduce fiscal control outside of Aleph, so certain kinds of e-book collections, e.g., Academic Press titles, that require title-by-title invoicing will likely continue in Aleph, and, therefore, their descriptive metadata will likewise continue to be stored in Aleph (versus, say, Ichabod).]
[For easier future reference, I'm also posting my notes on the github wiki [14]].
Daniel
[1] http://guide.agilealliance.org/guide/backlog-grooming.html [2] https://www.pivotaltracker.com/story/show/73890534 [3] https://www.pivotaltracker.com/story/show/67578010 [4] https://www.pivotaltracker.com/story/show/67209752 [5] https://www.pivotaltracker.com/story/show/73888330 [6] https://www.pivotaltracker.com/story/show/67578010 [7] https://www.pivotaltracker.com/story/show/68319844 [8] https://www.pivotaltracker.com/story/show/68322322 [9] http://metadataregistry.org/concept/list/page/1/vocabulary_id/45.html [10] http://metadataregistry.org/concept/list/vocabulary_id/46.html [11] http://metadataregistry.org/concept/list/vocabulary_id/37.html [12] http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements#H7 [13] https://github.com/projecthydra-labs/questioning_authority [14] https://github.com/NYULibraries/ichabod/wiki/Backlog-Grooming-Notes
We prepared for the Sprint Planning meeting on Thursday by pulling new stories from the icebox into the backlog and formulating acceptance criteria. As mentioned in my previous set of notes, the priorities right now are setting up the production beta instance and getting more collections indexed (starting with NGO PDFs and Rosy the Riveter).
We reminded ourselves that we're still assuming that Ichabod metadata will find their way into Primo. But that'a future user story.[1]
We created a new user story about CRUD permissions management [2], but left it in the icebox. We reminded ourselves that Grouper is appealing because it provides a a UI and is portable (e.g., not just tied to Fedora, can also be used with R*).
Scot mentioned that he, Barnaby, and Corey would be discussing the Ichabod technology stack on Thursday.
We discussed SSL certificates and that Ryan should be able to request as many as needed from University ITS.
We talked about the Production Solr story [3] and whether we'd want to use DLTS's ITS-hosted Solr server or WebSolr, or something else.
Scot volunteered to add 'tasks' to the newly-defrosted user stories.
I think that's pretty much it, other than what's captured in PivotalTracker. Hope it's helpful. Let me know if you have questions.
[1] https://www.pivotaltracker.com/story/show/66549904 [2] https://www.pivotaltracker.com/story/show/75974276 [3] https://www.pivotaltracker.com/story/show/73890768
We noted that several Ichabod members are tied up with Primo upgrades and not able to re-engage with Ichabod until Tuesday.
We determined that all Current stories have been assigned complexity points and owners in PivotalTracker.
We discussed and changed the label “metadata remediation” to “metadata CRUD”, since that seems a more accurate description of what’s involved. Remediation will come later as we explore tools like Open Refine.
We discussed the story about adding new elements to NYU Core [1], noting that the goal is to get all of the ‘touch points’ into one place (vs. six?) in the Ichabod stack, and thereby make extensions easier to implement.
We discussed the story about filtering on multiple collection facet values [2] and noted that this is more about Boolean intersections than unions, so possibly less complex to implement.
We discussed the idea of a 1.5 hour session to look at Ichabod from a higher-level perspective, share ideas, assumptions, interests, as we move forward. (Scot mentioned this in today's scrum.) For example, to what extent is Ichabod to be a publishing platform, a discovery portal, and/or a metadata remediation tool? What does the minimal viable product look like? Scot will schedule a meeting time.
- Daniel
[1] https://www.pivotaltracker.com/story/show/71678786 [2] https://www.pivotaltracker.com/story/show/71324512