Adding imports to ontologies is a little cumbersome

[sesuncedu]

The process for adding imports to an ontology seems a little cumbersome.

1. Setting the new entity prefix to http://www.w3.org/2002/07/owl# ,
2. Creating a class "Ontology" and an annotation property imports,
3. Setting the new entity prefix to all but the last entry of the ontologyIRI,
4. creating an instance of owl:Ontology,
5. annotating it with owl:imports with a value that is the desired import ,
6. downloading the ontology,
7. uploading the ontology into a new project

...seems a little convoluted.

Also, the exported turtle looks a little odd. It does regrettably still seem to be legal OWL2-DL.

<http://example.org/onto-2> rdf:type owl:Ontology ;                      
                            <http://protege.stanford.edu/webprotege/revision> 26 ;                          
                            rdfs:comment "A test of little importance"^^xsd:string ;                            
                            <http://purl.org/dc/elements/1.1/date> "Mar 20, 2014 4:23:24 PM"^^xsd:dateTime ;                           
                            rdfs:comment "This ontology was generated from an ontology revision in WebProtégé http://webprotege.stanford.edu"^^xsd:string ;                            
                            <http://purl.org/dc/elements/1.1/creator> "sesuncedu"^^xsd:string ,
                                                                      "system"^^xsd:string ;                            
                            owl:imports <http://example.org/onto-1> .
[...]
###  http://example.org/onto-2

<http://example.org/onto-2> rdf:type owl:NamedIndividual ,
                                     owl:Ontology ;                       
                            owl:imports <http://www.w3.org/2004/02/skos/core> .

[matthewhorridge]

The tools doesn't really deal well with imports management at all at the moment. This is a rather elaborate way of getting around that :)

Ultimately there needs to be a nice way to edit the imports closure of a project and refresh imported ontologies that are cached etc.

[sesuncedu]

Direct import changes seem relatively straight forward (though I assume there's currently no listener set up to broadcast import closure change notifications to concurrent viewers

Changes to an imported ontology seem a veritable canapé of worms- if both ontologies are in the same project changes could propagate in real time, but that might need some heavy data factory mods.

[matthewhorridge]

Direct import changes seem relatively straight forward (though I assume there's currently no listener set up to broadcast import closure change notifications to concurrent viewers

At the moment, we don't generate events for this (potentially, the number of events for this is huge - we probably need some high level event that causes views to reload themselves).

Changes to an imported ontology seem a veritable canapé of worms- if both ontologies are in the same project changes could propagate in real time, but that might need some heavy data factory mods.

I think out biggest issue/challenge is dealing with a very large numbers of changes and propagating these to clients.

[hemed]

@sesuncedu, did you find any workaround on this issue?

[lonniev]

If we want to have two (or more) webprotege projects in an imports relationship, for example Project A and Project B where B imports A, then what is the URL or URI for Project A such that Project B can import it?

Neither the New Entity IRI nor the public webprotege Project URL appear to work. Is this an unavailable capability at the moment?

[lonniev]

Also, it seems that it might be easiest to build the import statements in desk-Protege first and then upload the skeletal ontologies to webProtege. The work of @sesuncedu is a bit complicated.

But, this is all contingent on being able to reference one webprotege project from another!