Back to imamuseum.org

Seeking a Common Language for Mobile Tours

It’s been several weeks now since the first Museum Mobile Summit was held in London at the Tate Modern.  As we told you in earlier blog posts (here and here), we had a good crowd in London and made some solid progress in our critique of the initial proposed TourML standard.  Notes from that meeting are available on the Museum Mobile Wiki and are interesting to glance through.

Since the meeting, we’ve been collecting thoughts and integrating the suggestions of the group into the formalized language description of TourML.  In preparation for the next Museum Mobile Summit on Wed Oct 26 in Austin, TX, we’ve updated and reworked the TourML specification to address the results of the first meeting.

I’ll say that TourML is feeling much more complete and much more like the real-deal.  As always, we’d love a lot of comment and input from the community, and would love to hear about ways you would like to use mobile tours in your museum.  We’re already seeing a number of museums building and creating mobile tours using the early version of TourML and the vendor community has been very supportive of the effort as well.

For those technical and metadata experts in the crowd,  you can download a new version of the TourML XMLSchema or browse it from the source repository for the TAP project you can also check-out a sample instance of some valid XML for a tour.  In the rest of this blog post, I’ll detail the changes that have been made to the standard, and will enumerate the reasons for those changes and some questions that still remain for discussion at the next summit.

Stops and Assets:

Perhaps the biggest change in the spec as a result of the initial meeting is the addition of Assets along with Stops as the basic elements that hold content in TourML.  Originally, Stops of different types each held links to their own media assets.  An AudioStop contained a link to an audio file, and so on.  By separating Stops and Assets we achieve a number of important features in the spec that we weren’t able to before.

Each Stop may contain links to multiple Assets which may be of mixed type.  This lets us create new types of Stops that potentially mix different kinds of media together. (i.e. a slideshow with an audio narrative running)  Also, assets for a stop may be defined that relate primarily to the design and user experience of the tour and not just the content of that tour.  For example, header images, icons, backgrounds and sound effects can all be defined as Assets and attached to a particular stop.  In order to tell the difference between how each of these assets should be used, we’ve also added some additional attributes to those Assets that describe their use on the stop.  In addition we’ve added the ability to indicate that an asset should be automatically played when a stop is initiated (“autoplay”).  This would be a great way to start an audio file playing as soon as the visitor reaches the stop.  This removes the need for the old GOTO feature of the initial TourML specification, and is a much stronger way of moving forward.

No More StopGroups:

In the original spec, StopGroups were used as containers for stops and were the way we conceived of linking those stops together for the navigation of a tour.  It was pretty clear in the initial Museum Mobile Summit that this concept was confusing to many.  What we came up with instead, is the concept of a StopReference.  Similar to AssetReferences (described above), a Stop may define a number of StopReferences, or pointers to other stops that a user should be able to use for navigation from that Stop.  This allows the tour author to create a narrative path of stops through the tour, and to offer choices to the visitor about what they might want to do next.  Like the AssetReference, StopReferences have some hints included with them as well.  Using the “navhints” attribute on a StopReference allows the author to designate particular stops as the “first”, “last”, “next” and “previous” stops for navigation.  Therefore, if the tour author wanted a “book-like” experience on a tour where each “page” in the book is a Stop… they could use the navhints attribute of a StopReference to indicate what the next and previous pages are.

There is still some thinking to be done regarding the implementation of the “autoplay” and “navhints” attributes.  It would be great to get some feedback from the community on those ideas and what kinds of values we might want to include with those attributes.

Multi-lingual

An obvious area of interest in the first Mobile Summit was the ability to create multi-lingual tours without needing to completely segment and copy the tour for each different language.  To address this we’ve added a number of language specific elements to Assets and Stops which allow the author to create one or more versions of the content in a stop but using different languages.  We think this is a pretty clean and easily understood way of including multi-lingual content in your next mobile tour.  Take a look through the spec and let us know if we’ve missed any elements that should support multiple languages!

Object Collections

One thing that the original TourML specification never addressed was the ability to include links to objet collections in a tour.  I know this is an application that many people in the community are using right now, and it needs to be supported well in any successful specification.

After asking around a bit and doing some research on my own, it seems the that LIDO specification offers a pretty good solution for describing many different kinds of object collections.  Rather than invent something new ourselves that wouldn’t be nearly as good, or have nearly the amount of thought as LIDO, we think it would be a good idea to reference that specification in TourML, and use it as the default object specification for museum tours.

This is a point that we’ll really want to talk over at the next Mobile Summit, and I hope some folks who are interested in object description (and maybe LIDO) will join us and help us to integrate it correctly.

Rights

As we all know too well, securing the appropriate rights and permissions for media we use in the tours can be a bit of a process.  To make sure that none of that information gets lost, we’ve added some elements to the TourML specification that seek to describe rights information and how it is represented in the tour.  We’ve even added the ability to assign a watermark to different assets on the tour.  Like many new things in the spec, AssetRights can be defined once and reused across many different assets in the tour.

Positions

As more and more of us create tours which rely on the location of users to correctly experience the content, it’s becoming more and more critical to correctly indicate the place of a stop during the tour.  We’ve added a Position element to the spec which exists on every Stop.  This position element can be used to record the x, y, and z position of the stop which can then, in turn, be rendered to a map or some other user interface for the visitor.  So whether you want to locate the new gallery on the third floor of the museum, or the latitude and longitude of where that artifact came from, you can now encode that information in TourML.  We’re also experimenting with the GML specification from the Open Geospatial Consortium to see if that will provide a nice way to tie museum experiences into other location based experiences.

Next Steps

While we’ve taken some great strides towards a more usable specification, we’ve still got a long way to go.  We really need the input of museums and vendors who will look at the descriptions and let us know where it works and where it doesn’t for their particular application.  Again, we’re shooting for a very practical 80% rule at this point in the game (see the previous blog posting), and also to be flexible enough to make TourML work for describing your next tour. Want to help?  Here are some things you can do to help move the process along!

  1. Read The Spec: It would be great to get a lot of eyes on this version of the specification as it incorporates a lot of the input from the first meeting.  For those that are not as comfortable looking at XML, we will soon update the text description of all the Elements and Fields on the Museum Mobile Wiki
  2. Attend the Meeting: While it might not be possible for everyone who’s interested to attend the next meeting, we really hope that lots of you will join us.  The meeting is FREE and takes place during the pre-conference workshops at the MCN Conference in Austin.  Thanks to the Museum Computer Network Board and Program Committee for agreeing to host this meeting for us!
  3. Give us Your Two Cents: Don’t be shy!  Speak up and ask your questions, give us your suggestions about how we can improve what we’re doing.  We completely re-wrote our first version based on the input for those who attended the London meeting.  If we need to, we’ll do it again, and again until we get it right.  We need input from museums, software vendors, academics and enthusiasts to attempt to synthesize something that represents the majority of what we need.  We’ll do our best to smooth out the wrinkles and we promise not to bite! :)
  4. Give us Your Examples: I know that many of you (vendors in particular) have your own XMLSchemas that you’re already using to build your tours with.  We’d really like to see examples of those and how they’re constructed.  This might be a shortcut to figuring out hard problems, finding consistency, and ensuring that the features you need make it into the final spec.  Please post any sample files or schemas to the Museum Mobile Wiki, or mail them to me directly and I’ll put them up for you.

Thanks, and see you in Austin!  -Rob

Filed under: Technology

4 Responses to “Seeking a Common Language for Mobile Tours”