1 / 17

Protégé/OWL Imports/Namespace facilities

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

keira
Download Presentation

Protégé/OWL Imports/Namespace facilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protégé/OWLImports/Namespace facilities Daniel Elenius <elenius@csl.sri.com>

  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. 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”/>

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

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

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

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

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

  9. U UA L ONTOLOGIES:

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

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

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

  13. NAMESPACES: A URIs IMPORTS: xml:Base URIs

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

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

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

More Related