BeAware project current state

In this post I am going to write about the current state of BeAware project, describe current problems and outline the nearest prospects. This post has a debating character, so any comments are highly appreciated in our googlegroup.

Let’s begin with BeAware’s heart – ontology.

I think BeAware’s ontology should satisfy the following criteria:
1. Be user-friendly. For example, it means we fix the tough set of properties for each event type
2. One of the competitive advantages of semantic technologies is the ability of inference. That’s why I think ontology should use it effectively (from the user perspective, of course). Now inference engine works out, for example, when user searches for all entertaining events (independing on underlying hierarchy levels quantity) or scientific conferences by all social sciences. Better than nothing… but this ontology side should obviously be improved.
3. Ontology should be a generalization of all events’ types occurring all over the world

I already told about it in the previous post, but I want to repeat it once more (in my opinion, it is really important). Ontology development is a very difficult and responsible task. It is difficult because we need to overview a huge amount of events occurring all over the world and generalize them into a convenient form for the end-user. It is responsible because as soon as ontology is stabilized, the backward compatibility restriction will be introduced and we won’t be able to significantly change the ontology (as there already will have been created events of different types and we will have to maintain them without semantics change).

Heere is a list of open questions concerning ontology structure:
1. Currently “musical concert” event is “entertaining event” inheritor. But, in my opinion, classical musical concerts deserve “cultural event” parent. According to the current approach, when root event types (root is visual meaning: all events are inheritors of Event class) refer to some sphere of life, it would be logical to create class “classical music concert” and derive if from “cultural event”). But I think it will ball up the users (and classical musical concerts will be created as just “musicalal concert” and become an “entertaining event”). May be the whole events types’ structure should be remade?
2. “Theater” event type has “theater art type” property (there should be a more laconical label…). Should we keep it this way or may be it would be better to extract opera, ballet, etc. into “Theater” class subclasses? On the one hand, it will lumber the ontology, on the other hand, current implementation won’t allow to add additional properties, for example, for ballet (technically we can do it, but in this case we will break the first criteria).
3. Are there any standardized science and sports classification? Current “kind of science” (at “science event”) and “kind of sport” (at “sport event”) hierarchies should surely be remade.
4. I have no idea where to put “exhibition” event type. There are a lot of exhibition types: pictures, dogs, IT (software, hardware, games), etc…
5. I can’t resist the temptation to create a new root category called “IT”. I am still successfully battling with it… but a more serious question arises: by what criteria should root events types’ be created?

Let’s go to the second point of this post – overview of geodata application at BeAware.

Every event is bound to some place where:
Place = City (GeoNames) + [Object (LinkedGeoData)], where Object is an optional parameter.

Due to event binding to GeoNames city I would like to give an opportunity to users to filter events by:
1. City
2. Country administrative division
3. Country
4. Countries union

But if you look at BeAware advanced search, you will see just geofiltering by city or country. Why?

First, I will explain the absence of filtering by country administrative division. Initial implementation allowed to filter by first three points of the list. But it made the filter object search very tangled: there could be city, country or country administrative division with the same name. That’s why I decided to explicitly write object type before its name:
But we can't determine the type of administrative division: state (USA), land (Germany), prefecture (Japan), etc. By reason of this uncertainty I decided to reject administrative division filtering for the time being. Looks like the only solution here is to use some general label like (“Country subdivision”) (or could there be a better solution?).

Now let’s discuss the fourth geofiltration method – filtration by countries unions. Currently GeoNames doesn’t support such a kind of geo/political entities but, as I know, Marc (GeoNames chief) is working on it. Also there is another way to implement this feature: make mapping (very simple mapping) between GeoNames countries and GeoPolitical ontology countries and filter by GeoPolitical ontology countries groups. I will find out more details about it and implement later (just didn’t have enough time to implement it).

Now let’s talk about the second event location “dimension”, about particular object from LinkedGeoData. Why not give an opportunity to users to filter events by exact object in the city? Looks like a rather useful usecase: you can get all plays at your favorite theater, all parties at a particular night club, etc.. We haven’t implemented such a filtration because it depends on decision whether will we allow users to create custom objects (if they can’t find appropriate one) or not.

That’s all for today. Next time I am going to write about advantages of using RDF geo datasets GeoNames RDF + LinkedGeoData instead of relational GeoNames + OpenStreetMap.