Ontology for events' storing platform

Question

I am building the events catalog site[1, 2, 3] based on Semantic Web technologies/approaches for my master's thesis (alpha version is avaialable at http://beaware.at). Looks like SemanticOverflow is the best place to get feedback/critics and eventually make the project better :)

I have posted a full list of unresolved problems and open questions at (2). But at this message I want to consult on ontology (here is it's actual version) related questions.

BeAware's ontology is built around events types hierarchy:

There are basic properties and properties which are specific to some event type (for example, "Science field" property for "Science event"). I'm implementing OOP-like inheritance here (so "Science conference" extends "Science event" properties set).

Here is a list of open questions concerning ontology structure that confuse me:

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”). Another solution is to combine cultural and entertaining events into something like "Arts, culture and entertainment". I'm not sure which solution is better.
“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 it will break natural model of binding properties set to specific event type).
Are there any standardized science and sports classifications? Current “kind of science” (at “science event”) and “kind of sport” (at “sport event”) hierarchies should surely be remade.
I have no idea where to put “exhibition” event type. There are a lot of exhibition types: pictures, dogs, IT (software, hardware, games), etc…
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?

I would be very grateful for any feedback.

P. S. Any not related to ontology feedback is appreciated at BeAware googlegroup.

Introduction to BeAware: http://alexidsa-en.blogspot.com/2010/06/beaware-project-alpha-version-has-been.html
BeAware current state: http://alexidsa-en.blogspot.com/2010/06/beaware-project-current-state.html
RDF vs. nonRDF for geodata at BeAware: http://alexidsa-en.blogspot.com/2010/06/rdf-vs-nonrdf-for-geodata-at-beaware.html

Accepted Answer

3

To give you a short and simple answer, forget about overly hierarchical structures, you have many ways to model this, and on the semantic web you do not need to bracket things off as having a single 'type', to illustrate and keep it simple, here's an example from a different domain.

<a.gif> rdf:type x:Portrait, x:Image, x:DigitalImage .

The other way to look at this, is why make a distinction, something is either an event or it isn't, and it may have multiple topics:

:myevent rdf:type x:Event ;
   x:category :art, :entertainment, :culture .

or

:myevent rdf:type x:Event, x:Concert ;
   x:category :music ;
   x:genre :classical .

What will eventually work I can't say, it's domain specific, however I can say that sticking with a rigid hierarchical structure and trying to shoehorn things in to a single type won't work, forget that and worry about describing things - you're working with graphs not trees :)

Best of luck.

link

answered 18 Jun '10, 01:00

Nathan
429●8
accept rate: 5%

@Nathan: I like the idea of multitype events in theory but it introduces ambiguity in practice (it is very bad as I am creating an end-user application). But as some events are really multitype, I think I will implement it eventually.

(19 Jun '10, 17:55) Idsa

At the moment I can't imagine forgetting about "overly hierarchical structure" of events types. Two level events hierarchy has two advantages comparing to flat model. Firstly, root level events are basic events, so if user can't find some specific kind of entertaining event - he will just create entertaining event. That's why I don't want to combine "Entertainment, culture and art". Secondly, thanks to inference engine it allows to filter, for example, all entertaining events.

(19 Jun '10, 18:00) Idsa

But on the other hand flat event types model would solve problems I have with musical concerts...

(19 Jun '10, 18:27) Idsa

Answer 2

There are no “right” and “wrong” taxonomies. There are only some that will work better for your use case, and some that will work not so well.

You should have rough targets for the shape of your taxonomy from the start—how many top-level concepts should it have approximately, how deep should it be, how many concepts in total? Should each concept contain roughly the same number of instances or does this not matter? Think about your use case to answer these questions.

Useful techniques for creating the taxonomy: Find a representative set of real instances, and choose top-level concepts so that roughly the same number end up under each concept (this will tell you wether “IT” should be a top-level concept or not). Use techniques from information architecture, such as card sorting, to figure out what goes under which concept.

Ontology for events' storing platform

Follow this question

Upcoming Events

Related questions