Manakin and geospatial metadata
(Adam Mikeal)
Two problems tackled: visualizing geospatial metadata, handling complex items
Background
- Repos have complex items (e.g. book scans)
- Metadata needs to move beyond Dublin Core
- Traditional approaches fall short
Collection
- Geologic Atlas of the US
- 227 folios, maps, text, photos
- 1894-1945, from the USGS
- economic geology and geography
Folios
- 10-40 pages per folio
- scanned at 300 dpi
- @100MB per scan
- a half-terabyte in total
- only complete scan of this series in existence
DSpace organization
- 1 collection, 227 items (one per folio)
- each item had multiple bitstreams (one per page)
- Extra bitstream, stitched-together, reduced-res PDF for screen viewing
- (this sounds familiar — it’s what I do with book scans!)
Geospatial metadata
- DCMI Dublin Core recommendation for longitude and latitude
- coverage.point, coverage.box
Problems with default DSpace
- interface optimized for items with only a few bitstreams (yes yes yes!)
- extremely cumbersome, long list, very large files, no info = user frustration
- can’t do anything with coverage metadata
- search results have zero context, no way to search across an area
- great collection, horrible UI that doesn’t leverage unique properties of the collection
Solution: Manakin
Item view
- root problem: complex item!
- exploring pages loses context (no sense of last/previous page, what folio it’s from, which item it’s from)
- gallery-style thumbnails for browsing (woo-hoo!) allow seeing the folio at a glance
- whitebox-style previews for detail view of pages; retain context
- customized metadata to show lat/long
- two download options: low-res JPEG or big TIFF
Manakin’s role
- override item-view template with XSL
- easily extends to complex item structures
- built-in METS allows images to be associated, correlated with each other
Collection view
- wanted a map-based interface
- chose Yahoo Maps for prettiness
- geographic coordinates available for all items
- put a clickable map in the collection view itself!
- user can determine coverage area
- visual explanation of collection coverage
Manakin
- override one template!
- XSL writes JavaScript to generate map (reads coordinates, etc. — isn’t that slow?)
- customized collection within existing repository
- search results also plotted on map via XSL/Javascript
- made a nice search-box interface
Quick to implement!
Results: better user experience, improved access, used unique features of the collection
Q: any Lucene customization necessary for custom search?
A: no
Q: releasing any of the code?
A: yes, it’s been talked about; needs to be genericized first