Semantic Enhancement vs. Integration Data-Model DSC Solution Example

Ontology vs. Data-Model Computer Skill Single Ontology Multiple Data models Person Person Name First Name Last Name PersonSkill PersonName NetworkSkill ProgrammingSkill Is-a Bearer-of Skill Last Name First Name Skill Person Name Computer Skill Programming Network Ontology provides a comprehensive hierarchical view of a domain as opposed to a flat and partial representation of a data-model

Sources Source database Db1, with tables Db1.Person and Db1.Skill, containing person data and data pertaining to skills of different kinds, respectively. Source database Db2.Person, containing data about IT personnel and their skills: Source database Db3.ProgrSkill, containing data about programmers’ skills: PersonID SkillID 111 222 SkillID Name Description 222 Java Programming ID SkillDescr 333 SQL EmplID SkillName 444 Java

Representation in the Dataspace Source Concept Predicate SE Concept Db1.Name Is-a SE.Skill Db2.SkillDescr SE.ComputerSkill Db3.SkillName SE.ProgrammingSkill Db1.PersonID SE.PersonID Db2.ID Db3.EmplID Representation of data-models, SE and SE annotations as Concepts and ConceptAssociations Blue – SE annotations Red – SE hierarchies Term Predicate 111, Db1.PersonID hasSkillID 222, Db1.SkillID hasName Java, Db1.Name hasDescription Programming, Db1.Description 333, Db2.ID hasSkillDescr SQL, Db2.SkillDescr 444, Db3.EmplID hasSkillName Java, Db3.SkillName Native representation of data and data-models as Terms and Statements

Index Entities Based on SE Index Entry Associated Field-Value 111, PersonID Type: Person Skill: Java Db1.Description:Programming 333, PersonID ComputerSkill: SQL 444, PersonID ProgrammingSkill: Java Dynamic model-driven definition of entities based on user preferences, e.g. users want to deal with Persons’ data, including data about Skills Index entities based on the SE and native (blue) vocabularies Leverages syntactic integration provided by DRIF, semantic integration provided by the SE vocabulary and annotations of native sources, and rich semantics provided by ontologies in general Entering Skill = Java (which will be re-written at run time as: Skill = Java OR ComputerSkill = Java OR ProgrammingSkill = Java OR NetworkSkill = Java) will return: persons 111 and 444 Entering ComputerSkill = Java OR ComputerSkill = SQL will return: persons 333 and 444 entering ProgrammingSkill = Java will return: person 444 entering Description = Programming will return: person 111 Allows to query/search and manipulate native representations Additional querying richness can be achieved by combining pre-materialization with query re-write Light-weight non-intrusive approach that can be improved and refined without impacting the Dataspace

Associated Field-Value … and without SE Index Entry Associated Field-Value 111, PersonID Type: Person Name: Java Description: Programming 333, ID SkillDescr: SQL 444, EmplID SkillName: Java Index entities based on native vocabularies However much manual effort the analyst is able to apply in performing search supported by the Index entries, the information he will gain will still be meager in comparison with what is made available through the Index based on the SE. Even if an analyst is familiar with the labels used in Db1, for example, and is thus in a position to enter Name = Java, his query will still return only: person 111. Directly salient Db4 information will thus be missed.

Ontology and Data-Model Skill Education Technical Education ComputerSkill ProgrammingSkill SQL Java C++ PersonID Name Description 111 Java Programming 222 SQL Database Amazing semantic enrichment of data without any change to data; enrichment that can grow and change as our understanding of the reality changes For this richness to be leveraged by different communities, persons, and applications it needs to be constructed in accordance with the principles of the SE