Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RDF-OWL Data Model"

(Context ontologies and the base Higgins ontology)
(RDF example)
Line 10: Line 10:
 
Since the Higgins ontolology is very simple and abstract,  [[Context Provider]]s will rely on other more domain specific ontologies to define a vocabulary to describe its specific domain.
 
Since the Higgins ontolology is very simple and abstract,  [[Context Provider]]s will rely on other more domain specific ontologies to define a vocabulary to describe its specific domain.
  
===RDF example===
+
 
The level of abstraction of the Higgins ontology makes creating a good illustrative example difficult. Nevertheless, we have created one simple example here: [[RDF Example One]] <--This is example is based on an out of data higgins.owl. It needs to be recreated.
+
  
 
==Java Interface to the data model==
 
==Java Interface to the data model==

Revision as of 00:52, 11 September 2006

The model uses RDF as the data model representation and uses the variant of OWL known as OWL-DL as the ontology (schema) representation.

Context Data

A Context Provider is responsible for supporting the Higgins Context Provider interface. This interface provides methods that allow navigation and update of what the interface assumes is RDF instance data. Behind this interface most Context Providers will use their own data models and maintain a mapping between it and the Higgins RDF abstraction. The core structure of RDF "triples" is briefly described here: One Page Intro To RDF.


Context ontologies and the base Higgins ontology

A Context is, in addition to being a container of RDF instance data as mentioned above, also a holder of the URL of its OWL-DL ontology. For those not familiar with OWL, it is a modelling language with roughly the expressive power of UML. The context's ontology in turn imports (uses) other ontologies, among which must be the foundational Higgins Ontology. The Context's ontology provides Higgins with a semantic description of the data structure it exposes at the Context Provider Interface.

Since the Higgins ontolology is very simple and abstract, Context Providers will rely on other more domain specific ontologies to define a vocabulary to describe its specific domain.


Java Interface to the data model

Aside from some management methods, most of the Context Provider Interface is concerned with supporting an interface to its data as expressed in the Higgins RDF-based data model. Rather than define our own API to data model (and its associated ontology model), we propose to mix in to the current CPI interface (currently IContext) interfaces we need from those defined in existing RDF APIs such Jena or as the Eclipse EODM component. EODM is part of the Eclipse EMFT project. The Javadoc for EODM is here.

[Historical note: In early 2005 the Higgins project proposed to IBM China that it release its EODM technology to Eclipse, IBM agreed and by Jan/Feb 2006 it was part of the EMFT project. The prototype Higgins Context Providers created to-date have used EODM internally, but the current CPI interfaces layer over and hide almost all of the underlying EODM interfaces.]

Benefits

  1. This proposal meets all 12 goals outlined here Revised Data Model Goals M4, and goes beyond them in a number of areas.
  2. We reuse a standard data model instead of inventing our own. We don't have to invest any more time on the data model. It is already done. We can use and reuse existing interfaces, code, tooling, editors, parsers, generators, etc. as well as communities and expertise in RDF/OWL technology
  3. We can use the existing XML (and other) serializations of the model and its schema


Background

  1. <more links to come...>

Back to the top