KAT:Meeting-2008-12-02

From Semantic Multimedia Wiki

• Messaging
  • snedMessage sould be extended with a receiver
  • arguments for new sendMessage-method: Type, Data, Sender(optional), Receiver(optional)

• Discussion on KATObject
  • dicussion led to more questions than answers
  • The different types of Data to handle are:
    • Content (Media)
    • Collections (of Content)
    • Events (seperate api)
    • Ontologies (dbpedia, OWL ontologies) consisting of individuals and concepts
  • From a semantics perspective the data is associated in various ways
    • Ontologies are used for annotation and to define the participants in events
    • Events are both primary objects (i.e. objects that are managed in the KAT) and also used for annotation of media
    • Collectiosn are also both primary objects and have an annotation aspect, but might also be annotated themselves
    • The content is primarily annotated using ontologies, events and collections, but from an event-centric perspective also document events.
    • Summarising: There is no strong hierarchical relation between the data types, but rather an associative relationship.
  • Hierarchical visualisation
    • Ontologies, events and collections can often be visualised as trees, however, there are often various ways to induce a tree on a knowledge structure. For dbpedia, at least 4 ontological structures exist, such as Umbel, Yasni, Wikpedia categories and the DBPedia ontology.
    • The facetted view is even more flexible and facets might organize in many ways that are independent from the underlying structure.
    • Therefore, a feasible solution seems to be the separation of the view on the data (e.g. in terms of a tree) vs. a data model representing the different types of data and the instances.
  • While we agreed on a (internal) tree-data-model for the navigator, doubts arised whether it would be useful to generalise content and metadata under a common (tree-data) structure. From the structural point of view, a generic superclass might help summarising common attributes, producing a slim interface (following the principle of analogy). But on the other hand, from a semantic point of view on the data, it seems wrong to generalise the different types of data since they are essentially different and coincidentally share some attributes (following the principle of seperation of concerns).
  • We decided each to think about the requirements for a data-model from the plugin's developer perspective (Query, Navigator, Browser) and let those requirements be the ground for further discussion.
  • The general requirements for the data-model are:
    • asynchronous
    • different sources
    • complete and independent
• next meeting: Tue, 2008-12-09 14:15