1. Multilingual Ontologies – Standards and Technologies Gerhard Budin University of Vienna Chair, ISO/TC 37/SC 2 22nd APAN Meeting NUS, Singapore 20 July, 2006

2. Outline Problem description Methods integration Multi-layer data modeling Multi-standard frameworks Multiple representation languages Interlinking and harmonization of standards and specifications Interoperability frameworks Integration of tools Examples from risk management ontology engineering

3. Problem Description 1.There is (still) a communication gap between formalized knowledge representations such as ontologies and users of information and communication systems, where such ontologies are used, also on user interfaces. 2.Although the Semantic Web has been designed primarily for machine-to-machine-communication, we need seamless natural language interaction workflows in (semantic) web services of any kind 3.While the Semantic Web is (still) essentially monolingual and the international lingua franca is English, there is a growing need for multilingual ontology resources as well as ontology-based translation services that overcome communication barriers arising from cultural-linguistic differences, lack of excellent command of English, need for high precision in communication, etc.

4. Need for integration of diverse methods As expressed in standards and implemented in technologies, the following traditions increasingly merge: –Ontology engineering standards, frameworks, technologies e.g. OWL (based on RDF), SKOS (also on RDF) (W3C), DOLCE/SUMO, description logic, frame logic, unified logic, annotation Types of ontologies (e.g. domain o., upper o., application o., task o.) Editors such as Protégé, Altova, OntoEdit, div. merging/annotation tools –Translation engineering standards i.e. various paradigms in machine translation and computer-assisted translation (language-based, statistical MT, Transl. Memories, patterns) –Terminology and language engineering standards (as the pre-requisite for and interface between ontology and translation) Terminology and lexical markup frameworks: TMF, LMF (ISO) Markup languages such as TBX (language industry+ISO) Lexical databases/ling.ontol: WordNet, Ontowordnet, EuroWordNet Linguistic enrichment of ontologies (e.g. FrameNet) Interaction mechanisms, translation of ontologies Integration of multilingual ontologies in machine translation processes

5. Diversity and interoperability Strong diversity of lexico-terminological resources –Data models, data structures + data semantics –Diversity of semantic, linguistic/cultural complexity and semantic depth/richness Diversity of user groups and their requirements Sheer quantity of resources Data interchange between organizations (within and across domains) as well as (distributed) data integration – early needs asking for immediate solutions History of data modeling History of interchange standards History of semantic interoperability management

6. Need for multi-level modeling architectures

7. generic interoperability framework terminological interoperability

8. Developing the Terminology Markup Framework in order to cope with this complexity-diversity Based on empirical studies and practical user-driven requirements analysis Markup/representation/modeling: XML, XMLS, RDF, UML Open standards strategy (ISO TC 37) –ISO 12620 Data categories – meta-model element + semantics registry (RDF) –ISO 16642 Terminology Markup Framework (TMF) – meta-model architecture and specifications (UML) –ISO 12200 – Terminology Markup Language (XML) Instance for language industry: TBX Termbase Exchange Format (XML) Instance for lexicography/publishing: LexML ISO 1951 –Lexical Markup Framework (LMF) (UML) –ISO 704 and ISO 1087 (foundational level) –ISO 15188 (workflow and collaborative issues) –Alignment with ISO 11179, W3C, OASIS, etc.

9. Introduction to TBX TBX® stands for TermBase eXchange TBX is a Terminological Markup Framework (TMF) markup language –TMF is an ISO standard (16642) TBX is consistent with ISO 12200 (MARTIF) TBX is maintained by OSCAR (www.lisa.org) The TBX specification is free Serving portability of resources across proprietary terminology management systems, as well as interoperability of application-specific resources

10. TBX structure A TBX file is an XML document A TBX file consists of: –A header that describes the file –A set of entries, one per concept in the termbase –For each concept, a set of terms, grouped by language, that designate the concept A terminological concept entry (termEntry) –Can be multilingual –Can be monolingual

11. TBX and Other Standards (1) TBX and ISO 16642 (TMF) (2) TBX and ISO 12620 (Data Categories) (3) TBX and SKOS

12. 1 : TBX and ISO 16642 TBX is a TML (Terminological Markup Language) of TMF (ISO 16642) (see Annex B) TBX maps to the TMF meta-model –A TBX file is a TDC (terminological data collection) –martifHeader provides GI (global information) –termEntry: TE (terminological entry) –langSet: LS (language section) –tig/ntig: TS (term section) A TMF DCS (Data Category Selection) in TBX is in XCS (eXtensible Constraint Specification) format TBX uses ISO 12200 for its XML style

13. TMF Metamodel Global Information (GI) Complementary Information (CI) Term Section(s) (TS) Term Component Section(s) (TCS) Language Section(s) (LS) Terminological (Concept) Entry/Entries (TE) Terminological Data Collection (TDC)

14. TMF and lexical resources In general, a terminological resource is organized into concept entries, each of which includes one or more terms designating a particular concept In general, a lexical resource is organized into lexical entries, each of which includes one or more senses of a particular lexical item (a word or phrase) A concept entry containing multiple terms can be split into multiple lexical entries, one per term, and multiple lexical entries associated with the same concept can be combined into one concept entry Link to Lexical Markup Framework (LMF)

15. 2: TBX and ISO 12620 All data categories in the default TBX DCS are taken from ISO 12620 ISO 12620 is organized as an online registry and serves as a meta-ontology for resource modeling and for resource interoperability

16. 3: TBX and SKOS A typical concept entry will contain a subject field to specify the domain of the concept. However, the subject field is typically some kind of hierarchy that is flattened into a string within TBX SKOS makes it possible to represent the subject field hierarchy as a hierarchy and then create a link within TBX

17. Simple Knowledge Organization System (SKOS) SKOS is an area of work developing specifications and standards to support the use of knowledge organisation systems (KOS) such as thesauri, classification schemes, subject heading lists, taxonomies, other types of controlled vocabulary, and perhaps also terminologies and glossaries, within the framework of the Semantic Web. - http://www.w3.org/2004/02/skos/ (Accessed on 3/17/06)

18. Sample SKOS Food Recipe Ingredient Restaurant Menu Item

19. Visual Representation of SKOS Food Recipe Ingredient Restaurant Menu Item AppetizerEntreeSaladSoup Grocery Store Item Homemade Item

20. GEvTerm Initiative The information previously used dealing with food has been taken from FooNaVar, a project of the GEvTerm Initiative. The GEvTerm Initiative is a terminological database that has committed to being fully TBX and SKOS compliant

21. C: Multilingual Thesaurus for Medieval Studies (MLTMS) Imagine the ability to search across web-resources using your native modern european language and find appropriate primary and secondary sources in Latin, French, Italian, German, Spanish, English, etc., based upon the meaning rather than the form of the search term. Imagine having a tool that would enable you to search for a concept and be able to construct the forms it has taken historically as well as the ability to link outward for both evidence and argument. Imagine a tool that would enable you to study the slippage of concept which is beyond naming. Imagine having a tool that can deconstruct ontological orders asking for different kinds of readings. http://www.mith2.umd.edu/thes/ (Accessed on 3/17/06)

22. Why did MLTSM use TBX? integration of terminological data from multiple sources; querying multiple termbases through a single user interface by passing data through a common intermediate format on a batch or dynamic basis; placing data on an FTP site for download by interested parties; peer review by colleagues of tentative entries - http://www.mith2.umd.edu/thes/ytbx.html (Accessed on 3/17/06)

23. MLTSM Sample personnel personne qui accomplit un travail copie ou d'écriture copiste entryTerm écrivain synonym scribe entryTerm

24. MLTSM Sample (Rendered with XSLT)

25. TBX HTML The last few slides have provided an example of rendering HTML from a TBX file. Here is a brief diagram of the process. TBXXSLTHTML Processed byResults in

26. D: Other Standards ISO 11179 and XCS, which defines a flavor of TBX, both provide a list of data element types XMDR RDF OWL Topic Maps/XTM

27. E: Tasks for TBX Encourage translation technology vendors to implement TBX Revise the specification Compare ISO 11179 to XCS Render TBX in RDF -> TBR for TBX-SKOS interoperability implementation TBR -> OWL TBX – TMX (translation memory exchange standard) TBX in Machine Translation applications

28. Ontology Editor Protege 11179 OWL Ontology XMDR Prototype Architecture: Initial Implemented Modules MetadataValidator (defer) schema-driven syntax checker Authentication Service (defer) MappingEngine (defer) Registry External Interface Generalization Composition (tight ownership) Aggregation (loose ownership) Jena, Xerces Java RetrievalIndex FullTextIndex Lucene LogicBasedIndex Jena, OWI KS Racer,Kowari RegistryStoreWritableRegistryStore Subversion

29. OWL, RDF & XML Schema used to specify XMDR as UML used for 11179 Edition 2 UML11179 Metamodel 11179 Relational Schema Relational Metadata OWL XMDR Ontology & annotations XMDRs Relax NG Schema XMDR XML Schema RDF Spec TRang XML Schema Language spec XML Objects Types & Cardinalities What things go in own files? Which property direction stored? Sequential ordering of properties Triples: binary labeled relationships

30. XMDR XML schema provides a number of important benefits… Schema specifies what is required as well as what is legal Divides metadata into files conforming to XML schema Normalizes data (ala relational one fact in one place) Facilitates XSLT transformations by reducing degrees of freedom to a canonical encoding within the RDF standard Relax NG used to create and check XMDR-it schema RNG validator enforces many OWL ontology constraints TRang automatically translates into XML schema syntax

31. From texts and terminologies to ontologies Using the Risk scenario –Termbase Export XML Domain Models – meta-models -> patterns –Text corpus Term extraction – comparative testing ProTerm, MultiTerm Extract, MultiCorpora Aligning with termbase Convert to RDF –Ontology import -> editor The MULTH-WIN Project as an example of methods integration:

34. Bornemisza

35. Terminological frame semantics INTERVENTION (ACTOR(S), ACTIVITIES/PHASES): RISK DETECTING (PRE-EVENT) -R-ASSESSMENT -R-PERCEPTION (X is risk) -EXPERIENCE (statistics, case studies) -OBSERVATION (monitoring) -METHOD -SATELLITE -PROGNOSES -R-ANALYSIS -R-FEATURES -SITUATION/CONTEXT (danger/hazard) -SIMULATION (course of events) -PROBALISTIC METHODS (safety) -RELIABILITY -R-IDENTIFICATION (DAMAGE) -R-SOURCE -DAMAGE CAUSE -VULNERABILITY (DAMAGE TARGET) -SUSCEPTABILITY (capacity/people)

36. Terminological frame semantics I. Pre-event B. Public awareness and planning, II. In-event: C. Events and response afflux/Hochwasser durch Aufstau BE [[TYPE=flood], [PLACE=], [TIME=]], HAVE [CAUSE [[ORIGIN=], [NIEDERSCHLAG [TYPE=]], [STAU [TYPE= Aufstau]]], DAMAGE [TARGET=, SOURCE=, DEGREE=]], HAPPEN [STATES=, PROCESSES=]] backwater/Rückstau BE [[TYPE=flood], [PLACE=], [TIME=]], HAVE [CAUSE [[ORIGIN=], [NIEDERSCHLAG [TYPE=]], [STAU [TYPE= Rückstau]]], DAMAGE [TARGET=, SOURCE=, DEGREE=]], HAPPEN [STATES=, PROCESSES=]]

37. Relationship modeling disaster general rain hail snow type origin cause percipitation man- made natura l Stau Aufstau `afflux` Rückstau `backwater` im Entwässerungssystem `drainage flood´

51. TBX-SKOS interoperability Differences –XML vs. RDF (-> TBX will be turned into TBR) –Inherent flexibility + open data modeling for a large variety of resources vs. traditional thesaurus data model as a default for a KOS (diff. scopes) –TBX has documented use cases and mapping tools -> language industry standard –Different semantics + vocabularies (12620 vs. thesaurus standard) Commonalities –Conceptual approach –W3C –Integrated applications in the future Vocabulary mapping (RDF)

52. Global Information (GI) Complementary Information (CI) Term Section(s) (TS) TMF Metamodel Term Component Section(s) (TCS) Language Section(s) (LS) Terminological (Concept) Entry/Entries (TE) Terminological Data Collection (TDC)

53. Global Information (GI) Complementary Information (CI) Term Entry Level (Level 1) Terminological (Concept) Entry/Entries (TE) Terminological Data Collection (TDC) Concept- Related Dat-cats Subject Field Note Definition SourceID Responsibility Date Transaction Adminis- trative Dat-cats Notes Concept System DatCats

54. Language Section Level (Level 2) Language Section(s) (LS) Language Section(s) (LS) Language Section(s) (LS) (LS * n …) Concept- Related Dat-cats Note Definition SourceID Responsibility Date Transaction Language- Related Dat-cats Notes Adminis- trative Dat-cats xml:lang Transfer-comment Equivalence Concept System Dat-cats Terminological Entry

55. Term-Level 3 Language Section(s) (LS) Term Section(s) (TS) Term Section(s) (TS) (TS * n …) Definition Term-related DatCats (TRD) Term Context Note SourceID Responsibility Date Transaction Notes Concept- Related Dat-cats Adminis- trative DatCats Term Section(s) (TS) Transfer- comment Transfer- comment

56. SKOS Vocabulary SKOS Core is a model for expressing the structure and content of concept schemes (thesauri, classification schemes, subject heading lists, taxonomies, terminologies, glossaries and other types of controlled vocabulary). The SKOS Core Vocabulary is an application of the Resource Description Framework (RDF), that can be used to express a concept scheme as an RDF graph. Using RDF allows data to be linked to and/or merged with other RDF data by semantic web applications. Resource Description Framework (RDF)

57. SKOS Graphs

59. RDF Representation of SKOS Graph milk by source animal buffalo milk cow milk goat milk sheep milk

60. Mapping TBX/12620 DatCats to SKOS Vocabulary TBX data categories (data element concepts in the sense of ISO/IEC 11179-3) contain instantiations of information that are expressed in SKOS using SKOS core vocabulary. Interoperability (a cross-walk between the two standards) depends on mapping between the two systems

61. Terminological knowledge engineering framework 1. meta modeling level: Terminology Markup Framework (TMF) Lexical Markup Framework (LMF) UML, RDF, XML DC selectionISO 12620 in RDF is the meta-ontologyDC selectionsubsets, value sets 2. modeling level Terminology Markup Languages, e.g. TBX Lexical Markup, e.g. LexML (ISO 1951) XML 3. resource level Terminological resources Lexical resources Markup, Annotation, Alignment, Analysis, Term Extraction 4. workflow level ISO 15188 and other workflow specifications govern resource management processes (logistics, organizational measures, maintenance, quality assurance, etc.)

62. Framework integration ontology translation engineering framework interoperable integrative multilingual applications e.g. MULTH-WIN project terminology and language engineering framework

63. Thank you for your attention Acknowledgements: Slides 9-27 together with Alan Melby, Sue Ellen Wright Slides 28-29 Bruce Bargmeyer Slide 33 Entry from the WordNet database Slides 35-37 WIN project (Rothkegel) Slides 39-42 Flood Risk Project Slides 44 WIN, 45: ThesShow Legat/Stallbaumer 46: GEMET, 47: Bandholtz, 48/49: Gangemi, 56-59: Miles/SKOS