|
|
|
28 Aou 2004
Local-i
The service offered by local-i is good example of a service that might benefit from microcontent. Local-i offerse users to search for restaurants. You can find restaurants by keyword search or by guided search using metadata. With keyword search you enter the relevant keywords for your, such as chean and good. This will result in a listing of restaurants. Each result entry contains the name of the restaurant (as link), the restaurant type, the neighbourhood, the rating, the number of expert reviews and the comments. It is possible to sort the results by name, price or rating. The guided search allows the user to select from a cuisine, a neighbourhood, an ambiance, price, rating or feature (award-winning, brunch, catering, etc.). It is possible to narrow (refine) a query using metadata. Clicking on a restaurant title reveals the address, a link to directions and links elsewhere on the web. Each link is presented by a title, a description and the URL. The links are divided in expert reviews and comments from diners.
The local-i service might benefit from two types of microcontent: Open(Restaurant)Listings, and OpenReviews. These types of microcontent are generated by people outside local-i and thus the authors of this microcontent are elsewhere. Let us assume that these authors take the responsibility to publish this microcontent themselves.
First we have the Open(Restaurant)Listing. This is information that describes relevant information of a (service) provider. This information might contain the name (title) of the company, its address, its phonenumber, the company website URL. For a restaurant one might add a pricerange of a meal, the type of restaurant and the features. As the restaurant is responsible for its own information, it might publish it as an OpenListing. Any service provider that needs this information can subscribe to the OpenListing of the restaurant. A restaurant might already have this information as it submitted it to a Yellow Page provider, but these can also subscribe to OpenListings. The restaurant is responsible for keeping this information up to date. Alexa has defined something in this field. It is a file that has to be saved as info.txt in the root of your site domain. This is a good first step towards an OpenListing. It might be useful to add more elements to this pre-OpenListing standard.
Diners who haven been in the restaurant might publish an OpenReview on their personal website. This OpenReview contains a link to the restaurant, a review description and a rating. These OpenReviews might be used by aggregators such as local-i.
One of the main tasks for local-i is to aggregate the OpenListings and OpenReviews and make them accessible and searchable for their endusers. Local-i has to generate an average rating for a restaurant from all the individual ratings. And local-i has to decide which OpenReviews come from experts and which not. Local-i must also check the quality of the data it receives and guard against misuse. In some cases (and most in the beginning) an OpenListing will not be available. Local-i can create a proxy OpenListing to fill in the gap, as she does now by buying the data of a YellowPage provider.
By combing OpenListings, OpenReviews and an aggregator in an open way each involved party can focus on his own competencies and responsibilities.