D5.1orig-Appendix B - Ontology and content mapping tool
| Warning: this is a copy of the D5.1 document as originally submitted to the EC.
To contribute please use: Appendix B - Ontology and content mapping tool.
Back to D5.1orig System Specification
General description of ontologies
The ontologies are the essential infrastructure for the Semantic Webs which enable automated information access and semantics of data for artificial intelligence. As result the SW (Semantic Web) will give new access instruments by means of automated agents to cultural content repositories. This makes us aware that the SW will give a great improvement to web services and content retrieval systems like visual search engines .
The ontologies can be built in different ways within the SW scope. As said, one important result would be the semantic access to digital contents (the meaning of a concept is supposed known in advance and the ontologies are limited to the structural relationships among concepts which are relevant for the query). The ontology building will allow the activation of cooperation processes among various artificial agents or by their assisting human activities.
Core ontologies are upper level conceptualisations that contain specifications which are domain independent: concepts and relations are based on formal principles derived from linguistics, mathematics, etc.
The DOLCE ontology (Descriptive Ontology for Linguistic and Cognitive Engineering [1, 5]), as a model for the building of the domain ontologies because of its rich and consistent structure and axiomatization, for its modularity and reusability and more specifically for its explicit conceptualisation of qualities and spatio-temporal descriptions. This model has a declared cognitive scope by using the ontological categories and concepts underlying natural language and human commonsense.
Taxonomy hierarchic tree
Considering Alinari’s taxonomy, each domain has a position in a rigid structured tree having a null node as root. In this model each keyword has a specific context, as example: "Person" in the domain of "Diet" is different from "Person" in the domain of "Justice". Moreover, the semantic path going from the leaf to the root is unique and different for each context. Using a tree based structure we guarantee domains to be maintained distinguished and the position of each word depends on its position along the tree (this is why it is a hierarchic tree). One of the most important consequences of this model is that once chosen a key along the tree, all the domain results are retrieved taking the tree-path elements.
Synonyms and related terms have great consequences on the taxonomy, influencing the property of uniqueness and the retrieval methodology. The behaviour of a synonym should be exactly as an alias of the related term: navigating the tree by the term should have the same effect as navigating it by means of the alias (the properties of the active domain must be preserved). The middle level and bottom level terms cannot be directly represented as a general tree can have more than six middle levels with almost 8.000 keywords and 6.000 synonyms and related terms (this is for example the case of Alinari’s). Synonyms and multilingual databases have commune issues. Adapting a thesaurus towards a multilingual system requires an enormous effort and attention: some concept and relationship can be derived by statistical analysis of terms occurrence in corpora, but this wouldn’t result in the kind of well-structured conceptual system.
The new domain ontologies have been constructed from the current taxonomy: we tried to maintain, where possible, the hierarchy of concepts and we reorganized the existing sets of concepts into aggregated sets which realized the new domains (such as "Sport-Motorcycle", etc.). The rules and relations that govern the new ontology had to be created ad hoc, step by step, according both to general-ontology and domain-specific needs (as described during next sections).
The scope of the ontologies that have been created is the description of specific domains such as "Family-Party" or "Sport-Motorcycle" by means of the constituent concepts and relations. The granularity of the modelling depends on the scope of the ontology that is going to be built in the sense of sets and subsets of keywords. We selected the concepts that represented each domain and at the same time we identified their sub-concepts and the possible relations that could link them together. The professional related ontologies need highly specialized glossaries (that could increase a lot the granularity) and rules. The domains considered here are culturally influenced (i.e. "Holiday-Beach" or "Family-Party" ontologies in Europe is not supposed to be the same as in Asia or Africa because some semantic concepts could be differently used such as "Clothing" or "Accessory"), nevertheless we tried to maintain the ontologies as modular as possible, in order to be adapted and further on customized. It does not mean that the ’cultural heritage repositories’ have different ontologies: the cultural influence on domain concepts will only need to be taken into account as well as the multilingual aspects.
A large portion of the documentation has been taken from the Web as it is a rich and updated resource of terms and concepts. In the case of motor sports domains we considered the manufacturer’s web sites such as: Ducati, Yamaha, Moto-Guzzi, Ferrari, Toyota, while for "Family" and "Holiday" domains we retrieved information from company’s documentation.
The scope of the ontologies that have been built is related to the specific scenarios which identify both professional and non-professional user applications to which the project tries to give support.
The scope of the ontologies that have been built is related to specific scenarios which identify both professional and non-professional user applications to which the project tries to give support. The ontological concepts should describe specific domains such as "Family-Party" or "Sport-Motorcycle" by means of the constituent concepts and relations.
The domain ontologies have some classes of concepts in commune: the concept ’Human-Face’ could compare in many domain ontologies. This would generate misleading results when querying for a ’Human-Face’ in a specific context. It has therefore been necessary to create some classes of concepts to be shared by the different domains (an example of "Human-Body" is represented by next figure).
The granularity of the modelling depends on the scope of the ontology that is going to be built in the sense of sets and subsets of keywords. The ontologies required great changes to the conceptualization of the existing knowledge base used: new rules and relations were needed in comparison to the existing knowledge base.
- The knowledge representation for semantic contents is the actual focus of our activity.
- We built the ontologies using RDF(S) standard format which is supported by OntoMat-VDE tool. This tool has been used during the visual description process for the extraction and ontology annotation by means of low-level multimedia features.
- The integration process required a domain ontology to be navigated and specific domain-concepts to be selected. This process generated the prototype instances of the domain concept and linked them to the extracted visual descriptors.
The hierarchy of the ontology must respect some general rules to guarantee the consistence of concepts and the coherence of the modelling. The following rules [3, 6] have been used:
|* Is-a relation: a concept "Z" is a sub-concept of a concept "Y" if every instance of "Z" is also an instance of "Y", as example: considering the core ontology, the concept "Hotel" is a sub-concept of the concept "Construction" as "Hotel" is a special kind of "Construction" and similarly "Construction" is a sub-concept of "Non-Agentive-Physical-Object", as "Construction" is a special kind of "Non-Agentive-Physical-Object" ("[sub-concept] is a special kind of [super-concept]"||).|
- Transitivity relation: as example, the concept "Fortress" is a sub-concept of "Construction" which is a sub-concept of "Non-Agentive-Physical-Object", consequently "Fortress" must be sub-concept of "Non-Agentive-Physical-Object" ("If B is a [sub-concept] of A and C is a [sub-concept] of B, then C is a [sub-concept] of A").
- Avoid cycling: is guaranteed by: "A [concept] cannot be at the same time a [super-concept] and a [sub-concept] of another [concept]"
- Naming of concepts: synonyms and language translation terms are just different names for a concept so we can avoid creating different classes that are synonyms ("Synonyms for the same [concept] do not represent different [classes]").
- Sibling hierarchies: are direct "child-concepts" of the same concept (only the root has no siblings): "All the siblings in the hierarchy must be at the same level of concept generality"
- Evolution of a concept hierarchy: considering the any domain ontology we must consider its future evolution and possible adaptation as it will be required to be inserted in more general ontologies as example "Holiday-Beach", "Holiday-Skiing", "Holiday-Camping" will contribute together to the more general domain called "Holiday".
Some relations can be defined if considering intelligent agents to retrieve image or video features:
- IsPartOf: if we compare an image as an irregular mosaic, then a concept or scene or even image element can be considered as a constituting element of the image itself. We can crop the sky, the sea, the water and each single item of the image analyzing it as separate object.
- Logical: typically the most commune logical operators are the Boolean AND/OR. The presence of an item-image could determine the context of the image itself: a red car having front and rear wings can represent a Ferrari Formula-One car. So the logical union/disjunction of some concepts would help to identify the attribution of an image.
- Temporal: the time relation is important more in video sequences than in still imaging. We can consider time relations also for still images if the creation time between two images is not too long (typically with sport imaging). A sequence containing coloured flat cars and people wearing protection helmets with the typical racing clothes can be attributed to motor–car sports.
- Spatial: a spatial rule defines the position relation among concepts. The sky above the water would suggest a beach scene; the sky above a large green area would suggest a country side scene.
- Relational: the proportion among concepts can be used to define if an image has some dominant elements. Two large blue coloured areas would suggest sky and sea, while a large dark area would suggest indoors scene.
Description of the interoperability specification aspects related to the adoption of the software module in different platforms
One of the most important problems encountered is the impossibility of importing automatically company’s existing taxonomies: SW technologies do not yet allow importing functionalities in this direction, also due to the large differences among the existing taxonomies. This implied the need of starting from a highly informal natural description of the objective ontology and its later improvement degree of formalism by restricting and structuring and lately generating the artificial and formally defined ontology into the RDFS  language with formal semantics inside an iterative quality process. This problem will affect most of the content owners and web portal managers as soon as SW will become market attractive.
To overcome this problem we foresee that the enlargement of the number of ontologies will soon reduce the discrepancy between the traditional and the new ontologies. Then, automated processes that are under study can be activated to migrate and generate new ones: the traditional ontologies should be mapped into the new ones with the heritage of rules and relations.
The interoperability of the ontologies cannot be evaluated because the building of the domain ontologies is still an on-going research activity.
Moreover it is not possible to adopt the tool sw module on any other platform than Microsoft (at least for what concerns OntoEdit). The good thing is the usage of the RDF(S) standard which allows interoperability and platform independence.
Relationships with other tools and components
The following picture explains the relationship of the Ontolgy and mapping tool with other architectural modules.
In Alinary, this tools are buikt using the following products:
- OntoEdit (or alternatively: KAON, Protege2000)
Different good tools are available and can be used to build the ontologies (Protegè2000 , KAON , OntoEdit , etc.). After testing different ones, we chose OntoEdit  (see also previous sections for the interface description) which supports representation-language neutral modelling for concepts, relations and axioms and it is based on a plug-in framework open to third parties extensions. Among the exporting formats OntoEdit allows the RDFS file format of the generated ontology . Usually the ontology tools have also a graphical interface that helps seeing the structure and the relations that have been built. Unfortunately, as soon as the structure enlarges a lot, the viewing of concepts and relations becomes more difficult and confusing.
We built the domain ontologies by using the OntoEdit tool: it supports representation-language neutral modelling for concepts, relations and axioms. OntoEdit is based on a plug-in framework open to third party extensions, and among the exporting formats it allows the RDF(S) file format.
To integrate the ontology knowledge with the content we used the OntoMat-VDE 0.512 tool for semi-automatic visual descriptor extraction and ontology annotation by means of low-level multimedia features. This tool supports the representations of the MPEG-7 visual descriptors using specific representation of visual features as texture, colour or shape that define the syntax and the semantics of a specific aspect of the feature as dominant colour, region shape, etc. (see next figures).
The two tools help significantly with the setting up of the ontology and the annotation. An integrated tool would increase the speed of both activities. In fact, while building an ontology that is related to images and videos, the cataloguer would be helped by a visual support during the concepts generation and also during the relation linking. On the other hand, the visual descriptor would already be revealed and the association would be speed up.
During the ontology building process, one of the most important problems encountered is the impossibility of automatically importing the archive’s existing taxonomies: SW technologies do not yet allow importing functionalities due to the large number of differences among the existing taxonomies. The enlargement of the number of ontologies should reduce the discrepancy between the traditional and the new ontologies.
On the other hand, the improvements that would have a good impact on the knowledge representation are related to the following:
Ontology Browsing: a searching function for concepts would help the annotation when the ontology dimension is very large (some ontologies contain more than hundreds of concepts).
Visual Descriptor Extraction: more automatic tools are needed to fasten the annotation process. We foresee the usage of an image segmentation module to ’suggest the selection’ of regions to be annotated; it would also improve the borders of the region selected (at this time the contour is drawn by hand by the cataloguer). Then, it would help to have some region operators to allow nearby regions to be added to aggregate sub-regions into one single concept-region (for example the human body parts into one single contour) or remove sub-regions from a segmented one (for example a human body shape from objects which interrupt the body contour).
The creation of new ontologies have put into evidence new ways to aggregate contents and information. The archive’s contents could actively interact by means of intelligent agents and semantics with other contents. The domain ontologies created had required to reconsider the original archive’s taxonomy and create higher levels of content knowledge.
Back to D5.1orig System Specification