ralphbln / aspect-owl-protege Goto Github PK

possible starting point: org.protege.editor.owl.model.search.DefaultSearchMetadataImporter.getSearchMetadataForAxiomsOfType(...)

From aspect-owl-protege created by RalphBln: ag-csw#11

If a class has an aspect in its definition, then this class becomes an aspect, too.

From aspect-owl-protege created by RalphBln: ag-csw#8

Shouldn't be too complicated. Since aspects are internally represented as OWLAspectAssertionAxioms, which are OWLAxioms, they can carry annotations. Just add an annotation button to the Aspect UI and see what else needs to be added.

From aspect-owl-protege created by RalphBln: ag-csw#12

If a class is an aspect, the aspect assertion axiom(s) that make it an aspect should be visible in the Class Usage view.

From aspect-owl-protege created by RalphBln: ag-csw#3

The current package structure is a mess. We should align our package naming scheme with the one used by the Protege and owlapi folks.

If a named class appears as an aspect in an aspect assertion axiom and the class is renamed the aspect assertion is lost. The aspect assertion should remain intact with the newly renamed class as the aspect.

From aspect-owl-protege created by RalphBln: ag-csw#2

Need to check what's going on there. Seems like the generation of explanations takes longer than before. If so, this issue needs to be forwarded to the protege or owlapi team.

From aspect-owl-protege created by RalphBln: ag-csw#14

OWLOntologyAspectManager.isAspectInOntology is highly inefficient. Whether a class (expression) is an aspect or not should be cached, and the cache needs to be invalidated only after a class (expression) has been added, edited, or removed.

From aspect-owl-protege created by RalphBln: ag-csw#6

From aspect-owl-protege created by RalphBln: ag-csw#10

(Inferred) aspects on inferred axioms should still be visible, but being able to edit them does not make sense, obviously.

Split the project into two projects, one containing owlapi-related extensions and the other containing protégé-related extensions only. This way it will become possible to use the AspectOWL and AspectSWRL-related extensions outside of Protégé. Some restructuring of packages and some refactoring will be necessary. #2 is related to this issue.

From aspect-owl-protege created by RalphBln: ag-csw#15

Write a wizard for the creation of new aspects. The wizard would allow the user to select from a list of preconfigured aspect types. An aspect type corresponds to a kind of modal logic. The kind of modal logic is determined by its axiomatization, which reflects in the combination of accessibility relation characteristics. An aspect configuration would therefore include

• an OWL class representing the aspect
• one or more accessibility relations (OWL object properties) with characteristics corresponding to the selected type of modal logic
• possibly one or more OWL individuals representing possible worlds (e.g. in case of a temporal aspect with known start and end instants, two individuals representing these instants would be created).

The complete temporal aspect example would look like this:

• Type name: "Temporal Aspect"
• Required user input:
  • name (will be local part of class IRI)
  • start (optional) and end (optional) instance (select existing or create new)
  • accessibility relation (select or create new)
• Output:
  • Aspect class
  • accessibility relation(s)
  • possibly individual(s)

Some aspects might share a single accessibility relation while others won't (all temporal aspects might share the same before/after relation, while an epistemic aspect will need one accessibility relation per agent).

For certain types of aspects it might be possible to re-use existing vocabulary/ontologies. E.g., temporal aspects might use the W3C time ontology's time:before and time:after object properties, and every time instant (possible world) might be an instance of time:Instant. There should be an option for configuring this. This would be a per-ontology setting.