| | 1 | = Developers' Corner = |
| | 2 | |
| | 3 | sorry - it's still in German |
| | 4 | |
| | 5 | == Goals == |
| | 6 | |
| | 7 | * Teilnahmefähigkeit für INRIA-Alignment Contest (datum?) herstellen |
| | 8 | * Similarity Flooding optimieren (Lizhen) |
| | 9 | * "Alten" PhaseTab-Algorithmus evaluieren (Björn) |
| | 10 | * Similarity Measures für den Vergleich von Instanzen (Property oder Displayslot -basiert o.ä.) |
| | 11 | |
| | 12 | == TODOs == |
| | 13 | * many |
| | 14 | |
| | 15 | |
| | 16 | == Ideas == |
| | 17 | |
| | 18 | * Da AlignmentGeneratoren die Ontologien nicht verändern (insbesondere: kontrahieren) können, wird ein "MetaOntologieAdapter" benötigt, der eine andere Ontologie (im Sinne des Interfaces) konrahieren kann. (und später auch expandieren?) -> siehe [wiki:adapters_composite] |
| | 19 | * "MetaAlignmentGenerator" der eine Ontologiereduktion vor dem eigentlichen Alignment durchführt, kurz: er entscheidet an welchen Stellen die Ontologie zu kontrahieren ist, und verwendet zur "Darstellung" gegenüber dem untergeordneten AlignmentGenerator den MetaOntologieAdapter. |
| | 20 | * Um Similarity Flooding zu optimieren, kann der Benutzer 2 Klassen aus den 2 zu vergleichenden Ontologien auswählen. Aus den 2 Klassen werden 2 Subgraphen generiert. Auf den 2 Subgraphen werden Similarity Flooding Algorithmus verwendet. Um die ganzen Ontologien zu vergleichen, wählt ein heuritisches Algorithmus die wichtigsten Klassen aus, basiert auf denen das ganze Ontologiegraph aufgeteilt wird. Danach wird Similarity Flooding algorighmus darauf verwendet. |
