"Wees" properties alleen op owl:Thing box

[LloydRutledge]

Kunnen we regelen dat properties zonder expliciet domain alleen op de owl:Thing box en form komen?
Zoals het nu ziet komen ze overal. Hier is een stuk N3 code:

@Prefix : http://www.semanticweb.org/lru/ontologies/2015/2/untitled-ontology-171# .
:WeesProperty rdf:type owl:ObjectProperty .
:TestClass rdf:type owl:Class .

Die genereert deze FF GUI:

Liefste komt die property alleen in de owl:Thing.

Deze functionaliteit draaide wel in de voorganger PHP versie van OWF. De SPARQL ervoor is in die PHP-code.

Zo is het geïmplementeerd als afleider van een bredere functionaliteit: dat elke property komt op bij de class waarvoor die zijn domain is maar zijn superclass niet. Met RDFS reasoning on heeft elke property alle superclass ancestors van zijn domain ook als afgeleid domain. En bij default hebben ook wees properties (zonder beweerde domain) toch owl:Thing als domain.

Dus als je een beweerde domain voor een property een bepaalde class geeft en die class subclasses heeft dan wil je regelen dat alleen die class box die property heeft en niet ook alle subclasses. Dus is deze de owl:Thing check maar dan recursief.

Is deze te regelen?

[AlexMekkering]

Ik ga hier een impact-analyse voor maken

[AlexMekkering]

Na een korte impact analyse bleek dat het probleem slechts in matchObjectPropertiesWithClasses en matchDataPropertiesWithClasses van OWLImport gedefinieerd was, alsmede een aparte behandeling bij het toevoegen van parents aan een lens.

Aangezien de impact waarschijnlijk laag is, heb ik daarom wat wijzigingen gecommit in r513 waarmee het waarschijnlijk is opgelost!

@TeunTheunissen, zou jij de wijzigingen willen reviewen?
Er lijkt heel wat gewijzigd te zijn, maar het merendeel is afkomstig van auto-formatting welke ik een ieder toch wel sterk aanbeveel voordat code ingecheckt wordt (Ctrl+Shift+f) zodat dit soort verschillen elke keer geminimaliseerd wordt.
De meeste wijzigingen zitten in getTopClassesOfProperty welke voor alle domains van een property het volgende bekijkt:

• indien een domain geen superklasses heeft of superklasses heeft die niet tot de domains van de property behoren is de betreffende domain een top klasse voor die property en zal de bijbehorende lens de property bevatten.
• indien voor een domain alle superklasses ook domains van de betreffende property zijn, is de betreffende domain geen top klasse en zal de bijbehorende lens de property niet bevatten.

Daarnaast worden ook propertybindings niet meer gedefinieerd wordt directe parents van een lens.

Hiermee zou dit probleem op een generieke manier moeten zijn opgelost en komen properties slechts voor op de lens welke een topklasse voor die property beschrijft (dit kunnen er wel meer dan één zijn).
Unit tests zijn nog niet geschreven, maar hier kijk ik dit weekeind denk ik nog naar.

[jbachh]

ik kwam tijdens functioneel testen voor #69 het volgende tegen:

leidde tot een lege informbox Person (de props waren wel in informbox owl thing aanwezig):

[LloydRutledge]

@jheijning dus de wiki export verdeelt de properties anders dan de GUI aangeeft? Dat is raar. Hoe worden ze verdeeld in de opgeslagen Fresnel? Die is een tussenstap. Dan weten we of de bug tussen de GUI en Fresnel ligt of tussen Fresnel en de wiki.

[jbachh]

De shown properties van owl:Things komen ook niet terug in fresnel in de personLens:

[LloydRutledge]

@TeunTheunissen ben jij de GUI naar Fresnel converter? Weet jij misschien wat het probleem is, of hij het kan maken?

[AlexMekkering]

Ik denk dat het probleem is dat de lenzen die op het scherm getoond worden, 1:1 vertaald worden naar lenzen in de Fresnel output. De output voor lens Person heeft daardoor geen properties die alleen op een Parent lens gedefinieerd zijn.

[TeunTheunissen]

@LloydRutledge ik ben niet de gui naar fresnel converter, maar de fresnel ontology wordt vertaald naar de gui. Bij bewaren wordt de fresnel ontology via jena bewaard in een file. Deze vertalingen zijn 1:1.
@AlexMekkering ik zal binnenkort de review doen.