From NeOn Wiki
|Current Version||[[current version:= <ask format="template" template="CurrentVersion" limit="1" searchlabel="" sort="version number" order="descending" default="no version available"> 1.x/Neonqa *</ask>]]|
|Homepage||[http://ontoware.org/projects/neonqa/ 1.x/Neonqa Website]|
NeOnQA introduces a novel approach to integrated distributed databases using networked ontologies. As our central contribution, we implement this approach by developing real life applications called NeOnQA to help integrating and querying distributed databases.
- We establish the mapping between ontology and database schema and also supports creating mappings between ontologies. The ontologies and databases can be distributed. We create ontology-database schema mapping by lifting database schema into an ontology that can be processed by reasoners, such as KAON2.
- We integrate the ontologies and mappings that are distributed and interconnected. NeOnQA uses Oyster ere as metadata registry to identify the remote ontology resource and propagate local resource.
1. Now we present two use cases to get started. In the first scenario, we intend to create a database schema mapping for the database FIGIS residing locally(Please note: Remote databases can be also accessed by specifying its IP address with the database name). The sample procedure can be as follows:
- Step 1: We should first connect to the database by specifying the database’s address, its user name and password. If the connection successfully established, the database schema would be automatically extracted as a tree-like structure as shown in Figure 1.
- Step 2: Now we can manually select a certain column to create an OWLClass-mapping, or two columns in the same table to create an ObjectProperty, DataProperty or AnnotationProperty. The creation of mapping entries is usually according to the semantics involving in the database schema. (Figure 2)
- Step 3: Do not forget to click the “save” button to persist this database schema mapping after all the necessary mapping entries has been created. (Figure 3)
2. Figure 4 demonstrates how we organize the local and remote resources by using Oyster:
3. Figure 5 is exactly the appearance of view “Registry”, including functionalities like:
- Turn on/off the server(including the KAON2 server mode and the services for network communication)
- Manage local ontology and modify its metadata
- Access the ontology and its metadata on remote peers, either through direct IP address input or through Oyster2 registered peer information.
- Set one of the managed ontology as the target for query (deliver the virtual ontologies to several peers for concurrent reasoning later)
4. The second view “Query Answering” shows as Figure 6, with functions like:
- Query answering with SPARQL
- Show the time interval for query answering