Definizione algoritmo prossimità per evidenziazione

[Lorenzo Lepore]

Qui andremo ad elencare gli assiomi (e le espressioni in essi) che dovranno essere considerati per la costruzione dell'insieme degli elementi di prossimità rispetto ad un altro dato elemento.

[Valerio Santarelli]

Cerco di riassumere i requisiti.

Data l'IRI di classe e ovviamente l'ontologia, il metodo deve restituire:

Un insieme di classi. In particolare:

1. tutte le classi figlie della classe selezionata
2. tutte le classi "sorelle" della classe selezionata, e non disgiunte da essa
3. tutte le classi padri della classe selezionata (quest'ultimo insieme si rende necessario se ad esempio una classe ha due padri diversi, oppure semplicemente per aiutare l'utente a ricostruire il percorso che porta alle properties evidenziate (vedi sotto)

Un insieme di object properties. In particolare:

1. tutte le object properties afferenti alla classe, ciascuna con in aggiunta (a) l'indicazione se l'object property è ciclica o meno (ovvero domain e range sono la stessa classe) e (b) la classe a cui la classe in input è legata attraverso la object property

• per object property afferente ad una classe, si intende una object property che ha come dominio o come range o la classe stessa, oppure una classe padre della classe; una object property che è coinvolta in un assioma di partecipazione obbligatoria con la classe (del tipo SubClassOf(Class1 ObjectSomeValuesFrom(ObjProp1 ClassExpression1), dove ClassExpression1 è una qualsiasi class expression, nel caso più comune, owl:Thing)

-Un insieme di data properties. In particolare:

1. tutte le data properties afferenti alla classe

• per data property afferente ad una classe, si intende una data property che ha come dominio la classe stessa oppure una classe padre della classe; una data property che è coinvolta in un assioma di partecipazione obbligatoria con la classe (del tipo SubClassOf(Class1 DataSomeValuesFrom(DataProp1 DataTypeExpression), dove DataTypeExpression è una qualsiasi datatype expression, nel caso più comune, rdf:Literal)

[Valerio Santarelli]

Per arrivare a questo risultato, dobbiamo credo considerare un primo step di normalizzazione degli assiomi di SubClassOf che hanno come ClassExpression "inclusa", una espressione del tipo ObjectUnionOf(Class1 Class2 Class3). Questi sono rarissimi in ontologie prodotte da Protégé, ma frequentissimi in ontologie prodotte con Eddy.
Per il momento mi limiterei ai casi in cui tutti i disgiunti sono delle IRI, ovvero delle Named Classes (non esistenziali per intenderci).

[Valerio Santarelli]

Fatto questo, credo che si possono considerare solo i seguenti tipi di assiomi:

1. SubClassOf, con a sinistra dell'inclusione una Named Class)
2. ObjectPropertyDomain
3. ObjectPropertyRange
4. DataPropertyDomain
5. DisjointClasses

Rimangono fuori sicuramente:

1. Assiomi di funzionalità e similari (che non servono)
2. Assiomi di SubClass con a sinistra una espressione di classe non Named, oppure a destra una espressione strana, tipo intersezioni, etc.

Da valutare:

1. Assiomi di SubPropertyOf tra due pbject properties e due data properties
2. Assiomi di EquivalentClasses tra due ClassExpressions. Se non ricordo male, in caso di gerarchia completa, Eddy comunque esporta l'assioma SubClassOf con l'union a sinistra, quindi potremmo anche per il momento non considerare le equivalent classes, se non nel caso di due Named Classes in equivalenza tra di loro.

[Valerio Santarelli]

Nel commento di sopra, nella definizione di object properties e data properties afferenti ad una classe, ho indicato di considerare tutti gli assiomi di SubClass in cui è presente la classe a sinistra, e qualsiasi cosa come filler del dominio/range del ruolo.
In effetti in prima istanza si potrebbero anche considerare solo gli assiomi di partecipazione obbligatoria semplici, quindi SubClassOf(C1 ObjectSomeValuesFromo(R1 owl:Thing). Vediamo un pò che differenza c'è a livello di parsing degli assiomi, se non cambia niente li consideriamo tutti, altrimenti solo questi semplici.

[Valerio Santarelli]

Qualche osservazione riguardo al codice della classe SimpleOwlOntologyDeductiveClosure (in sostanza sto cercando di ricostruire le parti del vecchio algoritmo di chiusura deduttiva che si possono omettere, dato che sono inutili).

• gli assiomi di tipo OWLDisjointObjectPropertiesAxiom secondo me si possono saltare completamente, non ce ne frega un granchè di derivare disgiuntezze tra ruoli
• idem per gli assiomi di tipo OWLDisjointDataPropertiesAxiom
• gli assiomi di tipo OWLDisjointClassesAxiom e OWLDisjointUnionAxiom invece giustamente secondo me vengono processati, dato che vogliamo essere in grado di proporre, data una gerarchia, i fratelli di una classe, ma a patto che non siano disgiunti
• tutto il metodo inferAllTrivials() si può saltare: produce una serie assiomi banali del tipo C1 \ISA C1 che non credo vogliamo produrre (non ricordo sinceramente per quale motivo servissero). Anzi, in particolare tutti gli assiomi C1 \ISA owl:Thing sicuramente non ce li vogliamo mettere perchè ci rende più difficile capire quali sono i "padri" delle gerarchie.
• anche il metodo addEventualInconsistency secondo me si può saltare, non ce ne facciamo niente delle entità inconsistenti (nel senso che se ce ne sono, vengono già segnalate al momento di avviare l'endpoint, quindi non ci si arriva proprio ad interrogare l'ontologia)
• nel metodo applyAllConceptIARules, le seguenti regole si possono ignorare, tanto tirano fuori cose che non ci servono:

1. pre-rule 21 operation
2. RULE 3 (costruisce il complemento di tutti gli assiomi, non ce ne frega niente)
3. RULE 15
4. RULE 16-1
5. RULE 18-1 e 20-1
6. RULE 19-1
7. RULE 21 (produce altre classi insoddisfacibili, non ce ne frega niente)
8. RULE 31
9. RULE 35
10. RULE 38
11. pre-rule 22 operation
12. Rule 5
13. Rule 17-1
14. RULE 18-2 e Rule 20-2
15. Rule 22
16. Rule 26
17. per-rule 24 operation
18. Rule 9
19. Rule 19-2
20. rule 24

[Valerio Santarelli]

In generale la forma di ragionamento che stiamo applicando sfruttando l'algoritmo a grafo della chiusura deduttiva è molto avanzata rispetto ai requisiti minimi che ci servono. Qualora ci dovessimo accorgere che ci si mette molto tempo, si può anche semplificare un bel pò.