Open Ontology Repository --Possible interaction with GEO/GEOSS/GMES

1. Open Ontology Repository --Possible interaction with GEO/GEOSS/GMES Ecoinformatics International Technical Collaboration  April 10, 2008 Research Triangle Park, North Carolina, USA Bruce Bargmeyer Lawrence Berkeley National Laboratory and University of California, Berkeley Tel: +1 510-495-2905 bebargmeyer@lbl.gov

2. Topics • Open Ontology Repository effort • Use in GEO/GEOSS/GEMES

3. Ontology Summit • NIST, NSF, MITRE, National Center for Ontological Research (NCOR), and others are organizing an Ontology Summit meeting in April 2008. • The theme of the 2008 Ontology Summit is the vision of an Open Ontology Repository. This vision forms the basis of the international Open Ontology Repository community. • This year's summit will support the effort to produce such a repository (or set of repositories) by serving as a venue - both virtual and face-to-face - in which many of the issues relating to the design, implementation, and ongoing use of an ontology repository can be discussed and ultimately resolved. • This is the third in a series of Ontology Summit meetings  See: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008

4. Two Foci • The theoretical aspects discussed in Ontology Summit Forum • The practical aspects of building an Open Ontology Repository. This is the OOR-Forum. • See: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository

5. OOR Charter • Promote the global use and sharing of ontologies by: 1. establishing a hosted registry-repository; 2. enabling and facilitating open, federated, collaborative ontology repositories; 3. establishing best practices for expressing interoperable ontology and taxonomy work in registry-repositories.

6. In the Process of Establishing • OpenOntologyRepository_Scope - documentation related to this OOR initiative's mission, charter, objectives, goals, terms of reference, definitions, scope, ... etc. • OpenOntologyRepository_Requirement - documentation related to the requirements of the "open ontology repository" we are planning to implement through this OOR initiative. • OpenOntologyRepository_UseCases • OpenOntologyRepository_Approach - documentation related to this OOR initiative's approach, and the process we will be using. • OpenOntologyRepository_Architecture - documentation related to the architecture of the "open ontology repository" we are planning to implement through this OOR initiative. • OpenOntologyRepository_Plan - documentation related to this OOR initiative's deliverables, timeline, milestones & deadlines, project plans, etc.

7. Scope • An ontology repository is a facility where ontologies and related information artifacts can be stored, retrieved and managed.

8. Message from Leo Obrst (MITRE) “I'd advise folks to look over xmdr.org (eXtended Metadata Registry) before they re-invent 95% of the wheels, including definitions, architecture, requirements, use cases, etc. Although XMDR, like the ISO “11179 Metadata Registry standard, is concerned with more than an ontology registry/repository, their notions are extremely salient to our effort. And no, I am not involved in XMDR, and am only interested in seeing that good work is recognized, and possible duplication of effort is avoided.”

9. Functional Requirements of a Repository for RDF/OWL • Provide Capability to Submit an Ontology to the Repository • Extract administrative and descriptive data from the metadata fields of an OWL ontology • Metadata should follow existing metadata standards • Submitted items should be tracked with version numbers (after determining the levels of granularity needed for versioning) • Generate a meta-card entry for the ontology • Provide Centralized Data Storage. • Ontology metadata (ontology metadata includes the source, date, version number and other core metadata as defined by appropriate standards bodies) • OWL ontology • RDF store • Linkage to XML and database data and documents • Metrics and Logging Requirements. • Provide data access metrics. • Provide data storage metrics • Provide audit logs of repository activity Functional Requirements Proposed by LeoObrst/2008.01.03

10. Functional Requirements of a Repository for RDF/OWL (2) • Provide User Services via a Web Interface to • Search metadata indices • Link from the metadata index to the specific OWL or RDF storage location • Browse repository contents • Provide visual representation of ontologies • Search RDF instance stores with ontology-assistance • Specify agent-directed searches of instance store content • Machine User Services • Query repository and triples store using a conceptual query language, such as SPARQL • Query the repository and triples store using REST • Query the repository and triples store using SOAP • Use an API to programmatically create, view, and modify repository contents • Define machine services in appropriate machine-interpretable format, such as OWL-S

11. Functional Requirements of a Repository for RDF/OWL (3) • Provide a Repository of Downloadable Web Tools • Define a process with criteria for determining what kinds of tools to make available • Provide an index to available tools • Provide search capability to available tools • Validation Requirements • Validate an OWL ontology to ensure that it is valid OWL • Confirm the RDF against its terminology defined in RDFS

12. Functional Requirements of a Repository for RDF/OWL (4) • OWL Services • Browsing Services • Query Services • Indexing Services • Provides services for external search engines and entity extractors to index and mine repository contents • Visualization Services • Edit Services • Validation Services • Annotation Services • Web-Page Markup • Semantic Search Services • Crawl and Index • OWL Semantic Search Services crawl and index OWL content on the Web. Users submit logical queries which are answered with exact data. It can broaden queries with simple inference, such as equivalence, inversion, generalization and specialization.

13. Functional Requirements of a Repository for RDF/OWL (5) • Reasoning Services • Provide services to check ontology consistency, build classification, verify concepts’ satisfiability and check entailment • Provide services to support rules and execute minimally automated deductive reasoning and proof • Import Services • Support importing of modular ontologies into larger ontologies; this is at least partially a function of the knowledge representation language itself.

14. Functional Requirements of a Repository for RDF/OWL (6) • Semantic Mapping Services • Schema Translation • Automatically generate translation code between database schemas with an OWL mapping specification • Visually-aided Mapping • A user would generate a mapping between an existing ontology and the ontology expected by the custom visualization tool. The data would then be translated according to the mappings. The resulting data can then be viewed by the custom visualization tool • Disambiguation • A user would generate a mapping between multiple ontologies to identify where classes and properties are the same. The data from multiple sources could then be imported into a repository where a reasoning tool can determine what objects are the same. The results could then be viewed in a browser

15. Functional Requirements of a Repository for RDF/OWL (7) • Ontology and Instance Versioning Services • Provide services to support semantic versioning of ontologies and knowledge bases (instances).   • Terminology to Concept Mapping Services • Provide services to support mapping user terminology to the concepts that represent the meaning of that terminology, using thesauri, lexicons, and other terminological resources.   

16. eXtended Metadata Registry (XMDR) What XMDR Brings to the Table: • Use cases - semantics challenges - and Requirements • Potential design specifications • Proposed specifications for ISO/IEC 11179 Edition 3 – A UML Model, definitions, and OWL ontology • Modular software architecture and open source software modules • Open Source XMDR software • Test content – concept systems including thesauri, taxonomies, ontologies • A group of participants (XMDR project) that has considerable experience in this area. See: XMDR.org

17. Third Party Software Modular XMDR Archtitecture USERS Web Browsers…..Client Software Metadata Sources concept systems, data elements Content Loading & Transformation (Lexgrid & custom) Application Program Interface (REST) Human User Interface (HTML fromJSP and javascript; Exhibit) Authentication Service Validation (XML Schema) Mapping Engine Search & Content Serving (Jena, Lucene) Metamodel specs (UML & Editing) (Poseidon, Protege) XMDR data model & exchange format XML, RDF, OWL Logic Indexer (Jena & Pellet) Text Indexer (Lucene) Registry Store standard XMDR files XMDR metamodel (OWL & xml schema) standard XMDR files Text Index Logic Index standard XMDR files standard XMDR files Postgres Database

18. GEO/GEOSS/GMES • The work addresses information challenges identified by major initiatives including the Intergovernmental Group on Earth Observations (GEO), Global Earth Observation System of Systems (GEOSS), and Global Monitoring for Environment and Security (GMES). The techniques and technologies developed will be useful for GEO/GEOSS/GMES. In particular, this work addresses priority challenges identified by the GEOSS Architecture & Data Management (ADM) committee to “enable increased interoperability across existing data management systems: • Identify & address integration gaps in data management systems • Utilize community standards for data & metadata • Enable integrated measurements, data, products & predictive models • Examine the need for future data management requirements.” • Architecture & Data Management (ADM) Working Group Report February 22, 2007. See: http://usgeo.gov/docs/USGEO%20Progress%20Report%202007-0321.pdf

19. GEOSS Architecture • As the OOR group proceeds, convey the OOR developments to GEO/GEOSS/GMES, particularly the GEOSS ADM for inclusion in the registry portion of the GEOSS architecture.

20. Acknowledgements • Leo Obrst, MITRE • Peter Yim, CIM Engineering, Inc. • This material is based upon work supported by the National Science Foundation under Grant No. 0637122, and USEPA. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation, USEPA or USDOD.