June 18, 2008

Defining information relevance for location based services – part 1

Posted in Articles tagged 3 pillars model, aggregation, di-so, geo-semantics, geo-tagging, geotagging, information relevance, LBS, siddey, twitter at 10:12 pm by siddey

Online location based services have a potential that we will not see fully realised until they can effortlessly present a highly structured pool of data relating to people, places and things. The next frontier of LBS will be the tools and standards supporting and identifying all of the metadata that should be used to define what geocoded information is relevant to you.

Beyond simply associating a lat/long address with a text-field description, relevant location based information requires us to examine more deeply the links that should exist between data and the possible uses of it.

As we move closer to seeing a more tightly knit but broadly aggregated online world, information service providers will be able to assist us to filter out much of the noise and distractions that exist right now (which is ever increasing as more feeds start spewing forth from social services like twitter, friendfreed, brightkite etc.)

I should clarify that at this point, I’m not talking solely about filtering information coming from people’s activity feeds. That’s certainly one requirement and you can watch a very interesting video at Chris Messina’s blog in which he discusses elements of this as they relate to social network interoperability. Chris’ DiSo project, among other objectives, is attempting to provide open standards for enabling the aggregation, filtering and migration of information across social networks.

My primary focus, however, relates to making sense of knowledge that has been attached to physical world objects (people and things). After all, that’s what location based services are all about. At this point in the evolution of the industry it’s still mainly about people and not so much the “things”. Maybe that’s because it’s human nature to think of ourselves first and the rest of the planet later. 😉 A good by-product to come out of any of the numerous social network data portability initiatives would be creating a simple means to be able to categorise, aggregate and attach feed data to real world objects.

Geo-tagging is already a very popular activity and thousands of people are currently labelling things via Google Earth / maps, Yahoo! maps etc. There are also a huge range of mash-ups to choose from, that mostly attempt to extract value from some of the already available geocoded data by making it searchable. If you haven’t yet played with these sorts of services, to help you visualise the potential, consider a flight-simulator view of the world where what you see before you is overlayed with an all-you-can-eat filterable view of geocoded information.

If you’re still not with me – take a look at this video from the guys at enkin.net. They’ve written a next generation LBS mobile application prototype that using the camera on your phone, overlays digital information on top of the real-world objects that you’re seeing on the screen. One word – wow!

Now, back to the context. Without some control and standards it becomes hard to filter out the gold from the mud and it also still means you need to span multiple services to manually interpret and aggregate everything that may be of relevance to the person or thing you’re researching.

So let’s take a look at what I call the “three pillars” model of LBS to better understand the pre-requisites for enabling the next generation of LBS.

The “three pillars” of LBS information relevance

The first pillar (timing and focus) relates to establishing whether we are interested in real-time or event-based geocoded information (timing) relating to people and things (focus). As an example consider;

i. Tell me who/what is around me (real-time) OR ii. Tell me who/what will be around me (event based)

This is the dominant form current location based services take. It’s kinda cool but not that useful on its own, especially if you want to be able to automatically drill down to explore levels of related information.

The pillars model adds more value over current implementations by suggesting that the secret sauce ties back to being able to tap your ever growing social and business networks by focusing upon filtering time relevant information emanating from people within the networks you wish to tap (and related networks of 2nd and 3rd degree separation). Of course information emanating from these networks still needs to be geocoded and further sub-categorised (one of the other pillars). This objective is aligned with related projects that have been initiated to standardise how people’s event/activity information is structured across the multiple social networks they are using (see this article from Chris Messina for more info). Here though we’re talking more than just activities as events in time – we want to interpret the intent and outcome of these as they relate to the location of a person or thing that we are interested in.

As an example, what if I told a service that I was heading to Vegas to see the Consumer Electronics Show and was keen to meet up with some people with similar professional interests to me. How could I tackle this automatically? Let’s take a look.

1. Firstly, I’m heading to a known location at a known future time, so I should be able to search my network and their networks for people whom have also indicate that they’re heading over also.

2. Secondly, I’ve got an open, well categorised profile (let’s pretend ok) and it’s therefore a no-brainer to select others travelling there with similar interests or background.

3. Finally, I receive my list along with their profiles and figure out who I’d like to send a direct message to. From there, if all worked out well, we’d attach notification of our plans to meet as tag information on the CES venue (yes, I mean the actual building) so that others will be able to see that we’re heading along when they query for event and attendee information attached to the venue (effectively a reverse look-up of the results of my own actions).

Dopplr is a service that covers one side of this equation (stating destinations for travellers) but to really get the value, we need to be able to add more qualifying information. In this instance the particular interests of the people would be relevant, not just that they’re travelling to the same destination. Besides, Dopplr is attempting to build a business out of what really should be a simple web service. Maybe if they opened up to us via an API!? 😉 By now you should be seeing the obvious need to link the functionality of currently disparate services to achieve the end game.

As another example, imagine if I Twittered the following, “@siddey needs a cheap hotel room within 100m of 101 Collins street, Melbourne, tonight”.

The service would interpret the parts of the whole as;

1. “needs a” – I’m looking for

2. “cheap hotel room” – cheap accommodation

3. “within 100m of” – defined geographical scope for search

4. “101 Collins street, Melbourne” – in the centre of Melbourne.

5. “tonight” – The timing, of course!

So the plan would be to search for hotels in the selected radius, identify if there are any associated discounts and/or general vacancies (through relating “cheap” as meaning discount/special etc.) available for tonight and narrow the search down to a handful of results. I’d then select the Hotel and auto-magically make a booking via an appropriately secure method (e-wallet anyone? :)). All achieved through a single sentence….wow. Maybe one day it would also recognise that in my roaming profile I’ve indicated that I’m a member of a particular chain’s frequent traveller club (by including my club id# etc.) and would pass my details automatically to the hotel to make a booking.

Although we see some of this dissection taking place in the current generation of location based services, the categories of information that both people, events and the real world have been tagged with are not yet standardised and nor are those focusing on location data particularly mature in terms of the data they capture and how they tag it (e.g. Brightkite). They are also arguably lacking granularity and exist as a myriad of discrete services out there with no single data dictionary to enable meaningful association of my vocabulary with the metadata fields currently used to store geo-coded information (although Mapufacture is certainly heading in this direction by taking a bottom-up approach). Other options would include use of specific Microformats.

Whether it be buildings, architecture, landmarks or other real-world objects to which we would like to link data stored in the vast array of existing online social networks and databases, there is a clear need to control our approach to associating physical and digital information across multiple sources using agreed standards.

The 2nd and arguably most complex piece of the relevance puzzle (the reason pillar) is intended to answer the question – Why should certain geocoded information be more relevant to you than the rest?

It’s primarily focused on the provision of real-time, situational information and intends to make decisions on relevancy for you based upon an assessment of your aggregated profile information. This would include a much deeper record of your interests, ideally populated automatically over time just by travelling, reading and conversing the way you currently would in the web world. Patterns would evolve over time and these patterns would result in narrowing down the information categories that are relevant to you based upon your current location and what it is that you’re doing (again we see a dependency upon interpreting events / activities).

The 3rd and final pillar in the model (geo-semantics) is the glue that binds it all and represents the application of semantic web principles to the real world. Included in this layer are the events I mentioned earlier that are being reported within our network of social and business contacts. After all, what use is semantically tagged online information in a location based context if we do not understand when and where information should be attached? The key here is to define standard metadata for real-world things that then allows us to more easily automate associating digital data with them. For inspiration, look back at the earlier example I gave above from mapufacture.com and try to think of ways in which the association of information and location could be automated instead of having to manually do this via their site. This should help you visualise what I mean by the obvious need to have a means to automatically detect that certain digital information applies to a real-world thing.

So with all of this in mind, we can see almost limitless possibilities for providing more readily available and relevant, location based information.

In parting, imagine that you’re an entrepreneur wanting to carry out market research for a new product and want to firstly identify and monitor geographic hotspots in which people are talking about your competitors. By researching the market demographics of the area and identifying the best areas and social networks (and people) to break into in order to pitch / sell would be extremely effective (although some might argue a tad intrusive but hey, it’s just an example).

Maybe you work in financial services and are travelling into “The Valley” to look for investment opportunities, therefore, you want to find out which are the key people and businesses operating in that space. You could find out the topics of discussion amongst the employees or their customers and prime yourself so that you can carry out due diligence from the perspective of market appeal, not just financials.

Perhaps you want to know the history behind the Sydney Opera House as it relates to your study of architectural design and ask questions of the various networks of people that have some form of relationship with that building / site.

Maybe you’re on holiday in Italy (yes, please) and whilst travelling on location you want the service to present to you all of the available audio tours, tours, restaurants and maps that your network of networks have also used and rated well and filter recommendations based upon those with similar tastes, travel plans and/or even by sub-category of tour. You may even want to narrow the criteria based upon the fact that you’ve only got 5 hours to spare in Milan, so time is previous and you need to consider how long all of this will take.

These are but a few of the complex queries that could be achieved through a single service with the appropriately deep definition of geo-coded information.

I do not have all the answers but I will be further exploring some of the dependencies I allude to above in future posts. Maybe a conceptual prototype will come following that.

Permalink 2 Comments