Protégé/OWL Imports/Namespace facilities Daniel Elenius

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 Import javax.swing.*; … In OWL, we have

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