ProtgOWL ImportsNamespace facilities

1
Protégé/OWLImports/Namespace facilities

• Daniel Elenius
• ltelenius_at_csl.sri.comgt

2
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

3
(No Transcript)
4
Not a new problem

• In programming languages we have things like
• include ltstdio.hgt
• Import javax.swing.
• In OWL, we have
• ltowlimports rdfresourceprocess/gt

5
Comparison, contd

• 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

6
Comparison, contd

• 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.

7
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 ftping to our web server, etc.
• Tell Protégé which things belong in which
  ontologies.

8
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.

9
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 xmlbase of the ontologies, not the
  namespaces or prefixes
• We need to start keeping these things separate
• The xmlbase is the URI of the owlOntology
  element, which every OWL ontology, i.e. every
  .owl file, should have
• These are the URIs that owlimports statements
  reference

10
U UA L
ONTOLOGIES
11
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

12
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 rdfabout
  statements to reference class a.

13
The Metadata tab

• Only shows info about the working ontology
• Import locations (xmlbase) 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

14
NAMESPACES
A
URIs
IMPORTS
xmlBase URIs
15
The Metadata tab, contd

• 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

16
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

17
Namespaces and prefixes, contd

• The prefixes used when showing classes/instances/p
  roperties 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