19 Mar 2015

Time: 1pm Eastern / 10am Pacific.

Call-In Info: Dial 1-530-881-1400, room 651025#

Moderator: Darren Hardy (Stanford)

Notetaker: Eliot Jordan (Princeton)

Attendees:

Agenda:

Roll Call
Call for Agenda Items
Next Call
1. Date: 16 Apr 2015
2. Moderator: Jack Reed
3. Notetaker: Bess Sadler
Review communication channels (hydra-community/hydra-tech mailing lists)
1. IRC Channels
  1. General recommendation is to use the main hydra channel until traffic increases to point where a new channel is needed
  2. Server: chat.freenode.net
    Channel: #projecthydra
Discussion on institutions' next steps toward a geospatial Hydra implementation
1. Stanford
  1. Launching of Hydra implementation for spatial data in April
  2. Working with PR department and timing launch to coincide with Earth Day
    1. Need to prove that the library is part of the scientific data management workflow and is relevant to the sciences to keep funding levels up
  3. Culmination of several years of work accessioning GIS data and establishing workflows for:
    1. Metadata creation
    2. Loading datasets into a spatial data infrastructure
    3. Adding layers into a discovery service
  4. GIS data is modeled in the repository for long term preservation
  5. Using common hydra ecosystem components: Fedora, Solr, Rails, Blacklight, GeoBlacklight, Solr
  6. Looking to migrate from Fedora 3 to 4 with linked data features and model GIS data as linked data
  7. Next steps are the launch and accessioning more GIS content
  8. Gearing up to do a GIS self-deposit interface within the next year
    1. Like Sufia for shapefiles
    2. Interested in collaborators
  9. One challenge is scanned maps without georeferenced control points
    1. Looking at how to accession georeferenced content into the repository that relates it back to the original scan and paper map
    2. Potentially using crowd sourcing for the georeferencing work
2. Berkeley
  1. In transition, but the plan is to go down the path with hydra
  2. Self deposit functionality on hold
  3. Currently have an OpenGeoPortal instance
  4. Have many digitized maps, and looking into how best to get metadata and spatial information for these
3. Univ. of Alberta
  1. The goal is to use Hydra as the repository for all digital collections
  2. Starting with implementing Sufia as an institutional repository in the next couple of months
  3. Historical collections, including maps, are next
  4. Scanned maps and shapefiles will probably come in as parts of other collections
  5. Scanned maps will be first follow by historical census data
  6. Alberta does have a Fedora repository with a custom interface, but are looking to migrate to Fedora 4
4. UC Santa Barbara
  1. Starting over on hydra project with new fedora, but haven't gotten to geospatial.
  2. Currently housing electronic dissertations and thesis, but will be moving on to special collections and scanned images
  3. Waiting for the geo component of the project to begin, but are looking at to using GeoBlacklight for discovery
  4. Right now, focusing on description and developing metadata standards and workflows for getting materials ready to go
  5. Have a lot scanned maps with MARC records with coordinate information, and are looking for ways to extract information from those as a starting point
5. Princeton
  1. Starting a twelve week push to implement hydra for a number a number of resource types including digitized books and born-digital materials
  2. Geospatial will not be part of these initial sprints, but scanned maps and geo datasets are on the horizon
  3. Plan to begin testing GeoBlacklight instance this summer for a potential roll-out in August
6. Notre Dame
  1. Hydra repository is one month old, and are in the planning stages for anything geospatial
  2. Repository is set up almost entirely for self-deposit
  3. Looking forward to self-deposit GIS material, but unsure of the demand
  4. Some of the geohydra tools are already rolled out on the smaller grant funded repository VecNet.
7. Univ. of Virginia
  1. Migrating GIS content from a 10 year-old custom system
  2. Skipping the hydra component for now, but are in contact with another group in charge of hydra implementation at the university
  3. Hope to have a production service by the beginning of the fall semester
8. Lafayette College
  1. Heavily invested in the Islandora system for digital repository front end
  2. Working on two early prototypes for managing geospatial datasets
  3. Managing shapefiles with a content model somewhat similiar to what one finds in the Islandora community, and trying to refactor that into a community solution
  4. Converting shapefiles into KML and GeoJSON, and simplifying the geometry with Mike Bostock's TopoJSON tool.
  5. Exploring the development of a Sufia instance in the Spring semester
  6. Have issues related to georeferenced tiffs.
    1. Currently managing as Islandora large image objects
    2. Have had some success serving these as raster maps via geoserver
9. Emory
  1. In the early stages of adopting hydra
  2. Attended most recent HydraCamp
  3. Have Geoserver and an instance of OpenGeoPortal
  4. Looking to migrating to Fedora 4
10. Virginia Tech
  1. Development group working on Fedora/Hydra repository
  2. Working with GIS librarian on test instance of GeoBlacklight
  3. University has a number of groups using GIS; some using GeoServer and others using ESRI products
  4. Each department wants to maintain their own data
    1. Idea is to standardize metadata and host it through the library's GeoBlacklight instance
    2. One discovery system points to data stored in each department
Hydra resources for the Interest Group
1. Conferences,meetings,workshops
  1. Hydra Camp
  2. Open Repositories: Jun 8-11, Indianapolis
  3. Hydra Connect: Fall 2015, Minneapolis
Identify specific common issue(s) for WG, perhaps:
1. XSLT to transfer between metadata formats
  1. 1. Stanford has a collection of XSLTs for converting ISO and FGDC to MODS and GeoBlacklight Schema
    2. Kim Durante will make these available to the group
    3. Jack commented that, in general, there isn't a great method for doing this and suggested that GeoCombine might be a good platform for developing these tools
    4. Kim mentioned that there are style sheets to convert from FGDC to XSLT
      1. Certain elements, IDs for instance, require extra work on the part of the institution
      2. This conversion is complicated by the fact that ISO standards have changed
    5. Darren spoke about GeoBlacklight Schema
      1. Dublin Core schema with additional elements that provide bounding box and other geospecific metadata
      2. Provides links to web services such as WMS
      3. Schema can be visualized with standard DC tools as well as ingested into GeoBlacklight
2. Issues at the planning stage for moving forward
  1. Migrating from Fedora 3 to Fedora 4
    1. John mentioned that they are working to implement Sufia with Fedora 4 and that from a metadata point of view, this represents a lot of change
    2. Perhaps group can look at the implications of Fedora 4 and RDF?
    3. There are a lot of unanswered questions about how Fedora 4 handles metadata that is more complex than basic Dublin Core
    4. Lafayette college is looking to explore this in December
  2. Querying against Linked Data
    1. James asked if there are there any services built on top of or integrated into Fedora 4 that would support querying similar to SPARQL
    2. Jack and Darren thought is was a good idea to split the administrative layer, which might use tools like SPARQL, from the end-user discovery layer into separate concerns
3. Shared Data Model
  1. The group decided that there was enough interest in developing a shared model for GIS data in Fedora 4 to initiate a working group
  2. Initial participants include: Darren and Bess from Stanford, James from Lafayette College, John from Alberta, Eliot from Princeton, and Jay from Emory.
  3. Bess will reach out to contact at the University of New Hampshire who is currently working on this
  4. Eliot Jordan volunteered to be facilitator