TourML (pronounced “turmoil”) from the Indianapolis Museum of Art is an attempt to standardize the data of museum tours. By exposing your tour content in TourML, you should be able to leverage the work of others and expose your tour on many platforms. Fundamentally, TourML should only represent the content of your tour while leaving the presentation decisions to individual applications.
In thinking about how to support the Information Architecture described by Nancy in her post, as well as support for a more traditional stop-based tour as described in the TAP application. It seemed to make the most sense to design the schema based around the concepts of “Tours” and “Stops” as these seem to be common terms. With some simple extensions, it seems that this architecture can also support the Soundtracks and Soundbites concept described by Nancy as well.
The architecture looks a little something like this:
- A Tour is a container for a collection of Stops.
- Tours have meta-data attributes like: Titles, Descriptions, Credits, etc…
- Tours might contain information about a set of top-level stops which are “entry-points” to the tour (not currently in schema)
TOURSETS: (not currently in schema)
- A TourSet is a container for multiple Tours which may be present on a single device. This is similar to what Ted presents in this overview of the DMA tours
- Stops are the primary object in the TourML schema, and contain references to the media files (i.e. audio/video/images) and navigation logic that makes this a mobile tour
- Stops can be of several different types which will change the way an application displays/renders them, and what information that application platform expects to find within the stop. Initial StopTypes include but are not limited to:
- Text / HTML content
- Image | ImageGallery (not currently in schema)
- Polls (not currently in schema)
- StopGroups are contain a list of other stops are are how an application can choose to construct a menu or list of stops
- Image stops with multiple images specified could be rendered as image galleries or slideshows
- Text/HTML stops might choose to make use of a wiki syntax in the CMS so that authors could easily link to other stops on the tour within some simple descriptive text… Those stops could then be rendered as thumbnails or links by the application device
- All Stops contain a certain amount of common data including:
- Type – the type of the stop as described above
- ID – a unique identifier for the stop, not for humans
- StopCode – a code (either numeric or text) which can be entered by visitors to access this stop. This might be a traditional keypad input… the answer to some clue… or an accession number from the collection.
- Icon (optional) – an override of a default stop-type icon
- Goto – a stop reference that should be accessed immediately upon finishing the action of this stop. (i.e. goto this image after playing this audio file; or, ask this poll question after watching this video)
- To implement Nancy’s example of Soundtracks and Soundbites we could construct a tour which has a string of audio-stops each of which could be separated by a StopGroup containing a series of choices of sound-bites which would invite the visitor to either dig-deeper or continue on with the sound-track. We could add an attribute to the StopGroup type which would automatically goto a particular stop after a specified delay. So we could play an audio/video file… offer a chance to dig deeper, and move onto the next section after 2 seconds.
This TourML XMLSchema is currently being developed.
- Multiple tours
- Location of WebStop linked resources
- Bundling content
- Navigation models? Could TourML represent if a tour is meant to be traversed linearly, by code, by geolocation, etc.?