Discussion of Protégé import/export problems - OWL-S Editor

looneyvillebiologistInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

86 εμφανίσεις

Protégé/OWL

Imports/Namespace
facilities

Daniel Elenius

<elenius@csl.sri.com>

Current problems


We cannot work with several ontologies


Nesting of imports not shown


Behaviour of ”imported” check box


No separation of import source & namespace


We have to reload the whole ontology for every
change


Not a new problem…


In programming languages we have things
like:


#include <stdio.h>


Import javax.swing.*;





In OWL, we have


<owl:imports rdf:resource=”&process”/>

Comparison, cont’d


In traditional IDEs:


We can edit different source files


Connected through import declarations


The notion of a
project
that keeps things together


In Protégé, the ”OWL IDE”:


We have one, monolithic knowledge base


Imported, but uneditable auxiliary knowledge
bases

Comparison, cont’d


The idea of one monolithic KB may work well
in some traditional areas that Protégé has
been used with (medical ontologies, etc.)


But the Semantic Web is based on
distributed

ontologies.

What we really want


Edit different (related) ontologies at the same
time


E.g. An OWL
-
S service and its related domain
ontology


Edit local copies, and choose a ”publish”
option to put it on the web


Publish by copying to our web folder


Or by ftp’ing to our web server, etc.


Tell Protégé which things belong in which
ontologies.


A Solution


We still work with only
one
KB at a time


Probably no changes in protege
-
main required


Users can still do everything they can do
now, as easy or easier…


But we also allow for more control and
possibilities when working with several
ontologies.


Our solution involves an
ontology panel
, and
changes to the
metadata tab
.

The Ontologies Panel


Add/remove ontologies to the KB


Create local copies of online ontologies


Submit local changes to online ontology


ftp, ssh, etc.


Select which ontology we are currently working in


All statements added by user are added to this
working ontology


Shows the xml:base of the ontologies, not the namespaces or
prefixes


We need to start keeping these things separate


The xml:base is the URI of the owl:Ontology element, which
every OWL ontology, i.e. every .owl file, should have


These are the URIs that owl:imports statements reference


ONTOLOGIES:

U UA L

The Working Ontology


Can be switched at any time without reloads


All statements added by user are added to
the working ontology


Window title bar should indicate working ontology
to keep user informed


Non
-
editable items are grayed
-
out


Statements in non
-
working ontologies


Statements in ontologies without local copy


Grayness thus changes depending on which
ontology is chosen as working ontology


An Example


Suppose ontology A has defined class
a
.


The user has chosen ontology B as working
ontology.


Class
a

will be grayed out.


BUT, the user can still
add
restrictions etc to
class
a
.


These will show up in ontology B using
rdf:about statements to reference class
a
.

The Metadata tab


Only shows info about the working ontology


Import locations (xml:base) and
namespaces/prefixes completely separated


But an ”add to imports” button spares the user
from having to write the same URI twice


Imported ontologies automatically added to
ontologies panel (and thus to KB)


Can not be removed, unless the import statement
is deleted


Will be grayed out unless local copies are made

NAMESPACES:

URIs

IMPORTS:

A

xml:Base URIs

The Metadata tab, cont’d


No ”transitive” imports shown


To see the imports of an imported ontology A,
change working ontology to A


Less confusion and clutter


User can edit exactly which ontology imports
what


(unless there is no local copy)


The imports seen in the metadata tab are the
same ones that will be in the corresponding
owl file

Namespaces and prefixes


The namespaces and prefixes shown in the
metadata tab are the same ones that will
show up in the corresponding owl file


Different files can have different prefixes for the
same NS.


No ”Alternative URI” field.


This is handled by the local copy functionality on
the ontologies panel

Namespaces and prefixes,
cont’d


The prefixes used when showing
classes/instances/properties etc in the UI, are
generated in the same way as currently


This only affects the UI, not what is written to the files


Perhaps there should also be the possibility to see the
”global view” of these somewhere


Namespaces cannot be removed/added manually


They are a function of which elements are referenced by
this ontology


But prefixes can be renamed