Library Torrent

Strategic Concerns for Developing a Web Maps Portal

While many people think that libraries are going to be made obsolete by the world wide web; actually, the opposite is true. Libraries serve as repositories of collections of informative objects, and information about these collections that allows objects to be discovered and used. IN this sense, the world wide web is creating many new opportunities for libraries and scholars to do their jobs in new ways and for people who simply want to enjoy the discovery and investigation of informative objects to find all sorts of delightful access to a variety of resources that are discoverable in new contexts -- like on your mobile computer while in the field - -not merely in a library building. The term that is beibng used for these new types of library activities is Digital Humanities (DH).

DH is essentially about figuring out ways of connecting information together in useful, interesting ways that are stable and repeatable. What is fascinating about DH is that figuring out how to connect information together requires subject matter experts to get together with information technology experts to develop that ways that information wil lbe described and the ways that web-based library tools will make different sorts of information accessible. This requires systematic collaboration -- which is in itself a new form of scholarship. Maps and information about maps will be playing an important role in DH, since maps are related to so many different sorts of things and events.

The problem facing developers of web-based map portals today are that the future capabilities of DH depend on standards and tools that are currently under development. This pioneering work is being carried out by communities of content experts and information architects and engineers. Eventually, there will be turn-key solutions for specialized portals like maps that are easy to install, maintain and upgrade.

To evaluate investments in technology, technical and non-technical leaders in the organization need to understand the emerging shape of the standards and services that are emerging for a certain set of specialized resources (maps) so that portal development can proceed to incorporate components that are relatively stable, and avoid inventing one-off solutions that are certain to become obsolete. This may be thought of as a strategy of moving forward while waiting. A major part of this strategy is to cultivate an awareness of what the leaders are doing. Participating in communities of developers with similar interests and using a selective, modular approach to development.

Components of an On-Line Library Portal

Thinking about portal architecture in a modular way helps to break the problem of web development into chunks and to incorporate pieces of software that can be easily upgraded and replaced. An essential aspect of the modular approach is to understand the functions that a particular module accomplishes, and the ways that information is passed from one module to another. A useful way to think about library portals for maps is to consider the architecture of a portal as having three major components or layers: \


These components may be further broken down as the repository includes representations of maps and metadata; the discovery layer includes indexes of metadata and interfaces for querying collections and for examining representations of maps. The presentation layer is where people put maps together with interpretive information. The presentation layer includes Authoring Tools and interfaces for exploration or for creating interpretive exhibits or perhaps combinations of georeferenced maps and perspective images in mobile applications. In some cases there may be a blur between capabilities in the discovery layer and the presentation layer. Nevertheless, it is useful to consider these divisions since it helps to keep straight how one set of decisions may affect or be made independently of other decisions.

For example, A well-adapted repository can enable any number of different tools and interrfaces for discovery or presentation. The complexity of beginning the project can be substantially reduced by understanding which requirements are part of the respository function so that a group of developers can focus on these functions without concerning themselves too much with how the discovery and presentation layers are going to work, other than the interfaces through which they will request and receive information from the repository. Thinking of the portal in terms of modules makes it easier to conceive of a coherent portal system that has flexibility as pieces of the system evolve and are improved by others. The aspect of components that makes them relatively easy to replace is the he idea that a module provides a certain interface to other components. These interfaces provide a means of more easily disentangling one piece of code from the system with relatively predictable results. And so, with this in mind, the interfaces or ways that modules communicate with each-other is one of the most critical aspects of portal design.

Resilience and Adaptability

The key to a successful library portal is that if the repository offers services according to widely accepted standards, then the catalog and presentation layers may be mixed and matched. If the repository and its services offer items with persistent URLs then there may be any number of scholarly tools that may incorporate documents from any number of authoritative repositories. This pattern of standards-based means of discovering and delivering content is exactly what made the World Wide Web a successful platform for developing and linking hypertext documents.

The essence of Digital Humanities is that there may be many ways of referencing and discovering content that are more specific and useful than full-text searches and URLs. For example, maps may be searched by their spatial extent or temporal references or according to keywords that have agreed-upon meanings. Once discovered, maps may be overlayed with one another in a coherent way -- even if the maps are coming from diffeent repositories. Other georeferenced content may be overlayed on top of the maps, including the locations of other library artifacts including photographs or images of artifacts. Just like in the greater web, the key to making information stick together in useful ways requires that th eindividual contributors agree to use standards.

Leaders, Communities, and Opportunities to Learn

I'll add links to this soon!


Simple Prototype Demonstration

To get our feet wet in portal development we can try a simple prototype. In this case we are using Harvard WorldMap as a repository that stores maps and delivers previews via several standards including Web Map Services (an ISO standard. On the presentation layer, we are using Omeka Neatline, which offers a great facility for pulling together resources (including WMS layers) to develop narratives. For now, our prototype has a simple catalog within WorldMap. But to my knowledge, this catalog does not interoperate via standard services. So there is room for extending this architecture. Several ideas for this are discussed later in this post.

Harvard WorldMap as a Ready Repository

Worldmap is a specialized repository and catalog for map data. Worldmap is a spiffy all in one system that is wired for collaboration. A great feature of Worldmap is its map warp interface (courtesy of another open source project.) that lets scholars pull their maps into a logical relationship with the earth and other maps. Worldmap also serves as a repository that delivers maps to any other client on the web that can use Web Map Services.

For this demonstration we are using the MapWarper functionality of WorldMap to create georeferenced maps in a simple repository that delivers georeferenced map tiles through Web Map Services. MapWarper is an open source project by Schuyler Erle, Shekhar Krishnan, and Tim Waters of Entropy Free. It is MIT licensed and the code can be found at github.com/timwaters/mapwarper.

Omeka Neatline: And WorldMap Working Together

Omeka is an open source, light-weight library repository, catalog and presentation tool all in one! Check out the Library Torrent Sandbox that is running on this web server. Omeka has a much more sophisticated Catalog system and presentation interface than WorldMap. It can't deliver Web Map Services on its own, but it can consume them. Thus, Omeka's map-based Presentation View provides a great way to demonstrate a resilient collaboration between independent tools sharing information based on a widely accepted standard. This presentation gets its maps from WorldMap!!

My Omeka Neatline exhibit is a little crude. There are some better demostrations of Neatline's capabilities here. I like the second one on this page. Collaborators on this project can request an account on our Omeka server that will permit them to add items to Omeka and create exhibits in Neatline. Here is a link to the user documentation for Neatline.. An important hint that is not in the docs:

Add a Map to Neatline

  1. Find or Create a Georeferenced Map with Harvard's Map Warp.
  2. Find the WMS URL for the map under MapWarp's Export tab.
  3. Right-Click the WMS Base URL and copy the link to the WMS URL.
  4. To reference this new map with a Neatline record, go to the Style settings for the record and enter the complete WMS url in th eblanks for both the WMS Address and WMS Layers

The rest of the Neatline interface is fairly well documented. We can have a meeting to do some hands-on collaboration once this collaboration gets rolling.

Possible Ways Forward

We can use this Pilot/Prototype as a means of demonstrating fun portal ideas, and as a means of experimenting with various ideas for more production-oriented portal architectures. As we build the collection of maps, we will not be able to depend on Harvard's instance of WorldMap. So next-steps for this project may be to investigate how a tool like Neatline might hook up to alternative repository and catalog components.

Hydra/Fedora as a Repository?

It may be that we would want to consider possibilities of using a poular library repository solution such as Hydra/Fedora. We are not aware the Hydra/Fedora that the current capabilities of Hydra include Web Map Services, it may be possible to come up with a reasonable substitute through the use of pre-tiled map previews. Potentially making use of something like The MapBox Tile Scheme (mbtiles) created with Tile Mill. This workflow would turn high-resolution maps into the nested-set of low-to-high resolution preview images (very similar to Zoomify) which can be served with a fairly simple web server plugin like TileStream.

If this avenue seems promising, then we would want to learn how to hook up our presentation tool (currently, Neatline) to Hydra/Fedora. It does appear that there is a Omeka Connector Plugin for Fedora that might be worth looking at. We should also expect to have to spend some time figuring out how to connect Neatline or our chosen presentation tool, to use the Tiels served from Fedora.

GeoBlacklight

BlackLight is a set of tools that provide quick faceted discover in fedora hydra repositories. For more information see Slides presented by Julie Meloni at an NYPL Brownbag lunch in 2011. The geo-libraries community is working on adaptations of blacklight to serve maps, as you can see by this slideshare by Jack Read of Stanford. While this may be R&D for tyhe moment. This activity is a good indicator of the utility of following well-known hydra/fedora conventions for storing geospatial images and metadata.

Open GeoPortal in the Catalog/Discovery Layer?

Our pilot does not have anything in the Catalog Repository Layer as it stands right now. Looking ahead, a possible candidate for this component may be Open Geo Portal (OGP), an open source project based at Tufts. OGP is gaining a lot of momentum with map libraries at Tufts, Harvard, MIT, Stanford, Berkely and Yale. OGP does not have a repsotory of its own, but references resources at local repositories that are harvested or pushed to a SOLR index. OGP users at Berkely and MIT have figured out how OGP can be used to serve map that are georeferenced through a simple Bounding Box entry. We might have to make modifications to get OGP to take previews from a mapbox tile set.

Presentation Authoring Tools with Linked Data?

While we are thinking about ways forward, we might begin to think about ideals for the presentation and presentation-authoring tools. Harvard WorldMap and Omeka Neatline both have interesting capabilities for adding annotations to maps. But, to my knowledge, neither of these has a capacity to treat annotations as collection elements that are catlogged in their own right. This idea of treating annotations as linkable data is explored in several interesting ways by the MapHub Project. It is current version, it is not clear how MapHub works with Repositories ,but perhaps this is worth looking into and keeping an eye on.