2011′s First Face to Face Meeting

The Points of Interest Working Group recently held it’s first face to face meeting of 2011 in beautiful Amsterdam, thanks to our generous hosts, Layar!

In this post, I’ll summarize what happened during the meeting.  You can read more about the meeting in detail in our minutes.

Day 1: administrative details, Core review & mappings

We had some new faces around the table, which made the first order of business introductions.  Welcome aboard Fons, Carsten and Dan!

The next order of business was to make sure everyone understood the process of getting our first working draft out the door.  We’ve made progress on it in the Wiki, but it is in desperate need of an editor.  Until someone else volunteers, I have agreed to step in to that role.  The process will be that anyone may suggest text edits via our public mailing list, which Matt will then integrate into the wiki document, and then into the proper format as we get closer to publishing.  We reviewed other procedural business, such as the POI Tracker tool, and generating requirements.  The group should be able to use Tracker issues more consistently now.

While we were discussing procedural issues, we also talked about our next Face to Face.  We’ve detailed a number of options for it, and as a result have generated a poll to help determine where it should be.  If you are a participant, please be sure to fill it out!

To round-out the administrative issues, we discussed a liaison request that we received from the Open Mobile Alliance, which is starting to develop standards for mobile Augmented Reality.   We agreed that we don’t want to have too many overlapping standards and that we would respond to the request positively and ask that they reuse our specifications where appropriate.

With administrative issues behind us, we then started the technical work.  First we reviewed many of the the key concepts behind the core draft such as the use of primitive building blocks, our format agnosticism, and how we will map our work to other formats.

Our discussions lead us to examining other related topics: using SKOS for categorization, POIs as Linked Data, querying POIs via GeoSPARQL, Open Street Maps map format, Facebook’s Open Graph Protocol, URIs as identifiers, and some real world examples.  We realized that the data we are dealing with can be represented on the Web in a number of different ways, and so we resolved that the group would only publish a single normative mapping, rather than trying to map our data model on XML, JSON, RDF, RDFa, etc.  We may have non-normative mappings and we will strive to make sure that any reasonable mapping is possible.  Dan summarized it thus: “The WG expects that broadly equivalent POI descriptions will be exchanged in the Web using at least XML, HTML5, JSON formats, often embedded within some surrounding format or spec.”

Day 2, Augmented Reality Landscape, existing standards, & categorization

Again we had some new faces, this time Thomas and Bertine, welcome aboard!  We recapped the previous day, and had some more interesting discussions about how we discover POIs.  The group resolved that: “There are lots of ways of identifying relevant POI descriptions, including GPS, QR Codes, image recognition (of specific things, of types of thing, of places, people, RFIDs). W3C POI data should be easily associated via various such techniques, and not be rigidly tied to any particular association mechanism.”

After the recap, we started looking at the Augmented Reality Landscape Note, which is one of the Working Group’s three main deliverables.  This note is where we examine the current AR related products and standards in order to determine what parts of the Web are missing that could help bring AR to the Web.  Jonathan collected information about the features of 14 different AR applications, for each of which the group determined how POIs are represented.  We added a few different capabilities to the list, as well as some existing and future standards that cover a portion of those features.

We then started to review existing standards that could be relevant to our POI specification.  Some of the standards we discussed include: sub-setting GML for representing locations, using HTTP headers to express various POI metadata and adapting iCalendar for recurring event specifications.  After everyone was up to speed, on those we moved on to discussing the Category primitive.

The Category primitive has been a hot topic of discussion on our mailing list and at our face to faces, but we were able to come to some agreement after looking at some already widely available examples from sources such as Wikipedia and Best Buy.  We resolved that while categorization information is indeed useful, it shouldn’t be required, and that defining a detailed broad category schema was outside of the scope of this group, though we may have a category schema in the AR Vocabulary Note.

Day 3, AR Vocabulary, GML, OSM, linking & names

We kicked off the day with a discussion of our AR Vocabulary Note, which we have not begun writing yet.  This Working Group Note will fill the gap between what is in the “core” POI Recommendation and those things that are needed to enable AR applications. One request was for rich representations of POIs in SVG, or a 3D model via X3D.  How could we extend the Core POI Recommendation to enable the discovery of that information in a standardized way?   We resolved that the ability to link between POIs was required.  We didn’t come to a resolution on how, and so we turned again to other standards.

We examined the Geography Markup Language (GML), which was envisioned as a schema language for creating other languages rather than a language that is directly used.  Some GML languages are simple such as GeoRSS while others can be very complex, like CityGML.

We then looked in depth at the Open Street Map (OSM) data format, which has a very simple schema, but it pushes the complexity down into the content and attributes of the <tag> tag, which is then managed via a wiki.  The OSM format was created for representing map-like data stored in a single large database.  It seemed likely that we would need to extend the OSM format to suit our needs.  There are some OSM based projects, such as LinkedGeoData (which creates an RDF knowledge base out of the OSM data) that have adapted the OSM data to suit more generalized needs.

Once we were satisfied that everyone understood the roles of these other formats, we switched gears to do some POI Core drafting, this time we worked on the “name” primitive.  We decided that since we were going to have only one normative mapping (to XML) that we didn’t need to go into details about things like what a string is, or how to handle different character encodings.  This should simplify things greatly going forward.

We also realized that the term “name” was possibly misleading, and as such we changed it to “label”.  We also decided that we need to support multiple labels, and a method to mark a label as the “primary” label for a particular language.

Identifying anything almost always leads to a discussion about discovery, uniqueness, ownership, de-duplication, etc, and this conversation was no different.  How do we find POIs?  How are they identified?  Who has authority over a particular POI?  How do we tell if two POIs are the same?  While we didn’t arrive at any definitive answers, we did have a great discussion that has led to a lot of follow-on discussions during our weekly calls.  As a group, our goal is to make POIs a first class citizen of the Web, and many of the issues we discussed have been addressed by the architecture of the Web for other types of data.  While we often focus on defining the format, we realized that we have to consider and provide guidance on it’s usage on the Web if we are to achieve our goals.

That was it for Day 3, and the end of our first face to face for 2011.  We’re already planning our next F2F, and hope to see you there!

-Matt

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you comment here, note that your IP address is sent to Akismet, the plugin we use to mitigate spam comments.