"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.

[TeunTheunissen]

@AlexMekkering review van de weesproperties, ik heb de code van de methode getTopClassesOfProperty bekeken die ziet er goed uit. Ik denk echter dat je analyse nog niet helemaal compleet is. Zie blz 99-101 van 'the working ontologist' daar staat de interferencie voor rdfs:domain en subclasses. Die interferencie laat zien dat een property die voor de domein classe geld ook voor de super classes geld van domein classe. Andersom geld het niet de subclasses van de domein classe zijn geen domein classe voor die property. Dat zou betekenen dat de weesproperty alleen bij owl.thing zichtbaar moet zijn maar properties voor de klasse TestClass ook bij de classe owl.thing zichtbaar moeten zijn. Dit zou een kleine aanpassing vergen in de methode getTopClassesOfProperty.

[TeunTheunissen]

@jheijning De gui wordt opgebouwd vanuit de gegenereerde fresnel, voor elke classe wordt een lens geinitialiseerd. De properties van die classe worden weergegeven en niets anders dus properties van super classe vindt je niet terug in de lens. Bij het bewaren wordt de frensel ontology weer als basis genomen en via jena in een bestand bewaard. Ook hier wordt elke lens en zijn properties weer vertaald naar een classe en properties.

[AlexMekkering]

Ik heb het boek er nog even op nageslagen, maar bergrijp je verhaal nog niet helemaal denk ik. Zoals ik het zie, kan met RDFS inderdaad met inferentie bepaald worden dat wanneer een bepaalde klasse als domein van een Property geldt, ook alle superklassen ervan als domein voor de Property gelden. Volgens mij geldt dan echter niet het omgekeerde, namelijk dat alle individuals van een superklasse die property hebben als predicaat. In bijv. het volgende voorbeeld:

• Als X :wifeOf Y
• Door inferentie van :wifeOf rdfs:domain :MarriedWoman geldt dan: X rdf:type :MarriedWoman.
• Door inferentie van :MarriedWoman rdfs:subClassOf :Woman geldt dan: X rdf:type :Woman.

Volgens mij geldt nu echter niet dat alle individuals van :Woman de property :wifeOf als predicaat moeten hebben, dus waarom zouden we deze dan opnemen in de parent klasse? Misschien ook wel, maar dan per definitie optioneel (niet mandatory) of misschien zelfs initieel hidden? Even een meer tot de verbeelding sprekend uitgangspunt: zou je in een formulier voor alle vrouwen, of meisjes, willen opgeven wie haar echtgenoot is, als die er is, of is dat veld alleen voorbehouden aan getrouwde vrouwen? Bovendien zal dan OWL:Thing per definitie alle properties van alle subklassen krijgen, wat denk ik niet wenselijk is.

@LloydRutledge, wat is jou idee hierover?

[AlexMekkering]

Het lijkt het me niet de bedoeling dat we RDFS reasoning gaan her-implementeren, daar zijn reasoners voor bedacht lijkt me zo. Toch heb ik, om te kijken of dit voldoende is, in r538 een regeltje aan OWLImport toegevoegd om alle parent classes van een topclass toe te voegen aan de set van classes waar de property voor gedefinieerd is. Wat bijzonder is, is dat Protégé OWL:Thing niet herkent als parent class van een willekeurige topclass. Indien nodig, is deze wijziging nog eenvoudig terug te draaien natuurlijk. @jheijning, wil jij hier nog even naar kijken?

Nog even iets over reasoning: Op dit moment lijkt Fresnel Forms niet aan reasoning te doen, zelfs als dat wel in Protégé is ingesteld. Dit lijkt me echter niet meer binnen onze scope te passen, aangezien hier een hele forse wijziging voor nodig lijkt te zijn:

• Er moet gekeken worden óf en welke reasoner in Protégé aan staat.
• Er moet gekeken worden naar óf de gebruiker de inferenties wil zien of de assertions
• Ipv de OWLAPI ontologie rechtstreeks te bevragen, dient hiervoor de betreffende reasoner gebruikt te worden wanneer de gebruiker de inferenties wil zien.
• Wellicht moet nog naar specifieke reasoner instellingen gekeken worden om te kijken welke inferenties wel, en welke niet moeten worden gedaan.

Daarnaast is mij de status van dit issue nu onduidelijk, daarom even de volgende vragen in het algemeen:

• Is het de bedoeling dat properties welke slechts in een parent class aanwezig zijn, zoals bijv. foaf:depiction, niet meer op de Person box verschijnen op de wiki?
• Zo ja, is het dan wenselijk om aan alle parent domains dezelfde properties te geven als de aangewezen topclass?
• Is het nog nodig om OWL:Thing, naast alle wees-properties ook alle properties van alle subclasses te geven?

Als we het eens zijn over deze zaken, dan kunnen we het meenemen in de final release. Anders zou ik de wijzigingen die we hiervoor hebben gedaan terugdraaien en terug naar de reasoning zoals uitgevoerd door Team 29, met grotere lenzen tot gevolg.

[LloydRutledge]

Volgens mij is voor ons zonder reasoning en simpel gehouden de algorithme zo:

1) Property voor een lens als die class beweerde is als domain van die property 2) Property voor de owl:Thing lens als die geen beweerde domain heeft 3) Geen lens voor een class tenzijn of (1) of (2) die domain is voor minstens één property

De bedoeling hiermee is dat elke property alleen bij één lens komt. Dit komt met (1) en (2). Uitzondering is als de property meerder domains heeft. Dan komt ie op de lens voor elke van die domains.

Dus ...

Is het de bedoeling dat properties welke slechts in een parent class aanwezig zijn, zoals bijv. foaf:depiction, niet meer op de Person box verschijnen op de wiki?

Ja.

Zo ja, is het dan wenselijk om aan alle parent domains dezelfde properties te geven als de aangewezen topclass? Is het nog nodig om OWL:Thing, naast alle wees-properties ook alle properties van alle subclasses te geven?

Nee en nee.

Klopt dit?

En nu het lange verhaal erachter:

De PHP OWF code implementeert een algoritme hiervoor. De kern van deze code zijn SPARQL query's die RDFS reasoning gebruiken. De algoritme begint met welke classes lenses krijgen. Die zijn alleen de classes met lenses die eigen properties zullen krijgen. Dus je moet eerste de proprerty-aan-lens toekenning uitvoeren, en dan alleen lenses met die properties gekregen hebben.

Die toekenning heeft natuurlijk de belangrijkste algoritme. Domains worden geërfd naar boven langs de subclass tree. Dus als een class en domain is voor een property, dan zijn alle ancestor classes van die dat ook. Dus moet je de leave node classes pakken uit de tree van classes die beweerde of afgeleide domain van die property zijn. us de SPARQL query met RDFS reasoning zoekt {property rdfs:domain class} waarvoor er geen {property rdfs:domain subclass} is. De bedoeling van deze algoritme is dat elke property in zo min mogelijke lenses komen. Als de property alleen één beweerde domain heeft dan zit die in alleen één lens.

owl:Thing is sowieso de domain van alle properties. Dus is die altijd een van de domains met deze algoritme. Als owl:Think de enige domain is voor een property kan kent die algorithme die property toe aan de owl:Thing lens.

Met die algorithm zal de owl:Thing lens geen properties hebben die in een "lagere" lens voorkomen. Dus, anders om gezegd, heeft die alleen properties die in geen andere lens voor komen. Recursief toegepast dus heeft elke lens geen properties die ergens in een lens voor een descendent class ook zitten.

Een property met meer dan één domain wordt ingewikkeld. Als je meerdere rdfs:domain triples hebben met dezelfde property maar aparte domains dan is de domain de intersection van die domains. Zouden we dus een aparte lens moeten maken voor die intersection waarmee alleen die lens die property heeft, maar daar heeft deze project geen tijd voor. Een rdfs:domain triple kan ook als waarde een union van classes hebben. Dan als een iets die property heeft dan is die van een of de andere classes (of allebei). Dan klopt het om die property op zowel de ene als de andere lens te hebben. Doet geen kwaad om die verdubbeling ook bij de intersection te doen. Dat is zo met de huidige algoritme.

[jbachh]

Concreet: De door jouw gevraagde aanpassingen hebben als resultaat dat FF (Fresnel en wiki-XML) bestanden exporteert waarin de PersonLens niet bijvoorbeeld de foaf:depiction (of andere owl:Thing) properties bevat. Alleen de properties uit de PersonLens worden meegenomen (birthDate, enz.) Een TBL ibox is dan dus niet mogelijk met de huidige ontologie \ABIsvn\Environment & Misc\Ontologies\DBPedia_TBL_Extract .

Is dat zoals je het wilt hebben?

[AlexMekkering]

Ik heb in r541 aangepast dat classes alleen properties krijgen wanneer geen van zijn superclasses dezelfde property bevat. Domeinen van properties met meerdere domeinen, mits geen van hen superclasses heeft met dezelfde property, krijgen allen die property. Daarnaast worden lenzen nu niet meer gegenereerd voor classes die geen enkele property kennen. Dit heeft ook een aantal aanpassingen tot gevolg in unittests, ofwel in code ofwel in gebruikte ontologie.

@LloydRutledge: Misschien is er nu wel een probleem met object-properties die een range hebben welke gelijk is aan een klasse die geen domein is van een property. Voor deze klassen wordt namelijk geen lens meer gemaakt en derhalve ook geen page/form/box op de wiki. Nu ik er zo over nadenk is er misschien ook helemaal geen probleem omdat anders de page/form/box leeg zou zijn, er zijn immers geen properties bekend.

@jheijning, zou je 't willen reviewen? de meeste wijzigingen zitten in OWLImport.getTopClassesOfProperty, OWLImport.getAllSuperClasses & OWLImport.filterEmptyClasses.

@TeunTheunissen, ik heb de bronontologie voor de sortproperties wat moeten aanpassen omdat :Movie geen properties had en er derhalve geen klasse meer voor aangemaakt werd. Wil jij er ook nog even overheen kijken of het goed is zo?

[LloydRutledge]

Shit, mijn algoritme knalt inderdaad de TBL voorbeeld. Goed gezien, Joop. Stom van me om dat niet eerder door te hebben. Mijn excuses.

En sorry, Alex: kan die aspect van r541 terug gedraaid kunnen? Of kan r541 in een branch apart bewaard totdat ik na dit project om die fatsoenlijk erin te zetten? Of minstens als r541 met de nieuwe algoritme moet blijven dan de release houden tot na de paper review? TBL is belangrijk in de review periode van de SWCS submission.

Het kan geredeneerd worden (zeker met WP iboxes als voorbeeld) dat de properties toch altijd geërfd worden: dat elke lens alle properties dan toch heeft van alle ancestor lenses. Dan gebruik je één lens voor alle domained properties in de hele superclass ancestor chain. Dat de gebruik alleen één lens ervoor nodig heeft zou gebruikersvriendelijke kunnen zijn. Het deugd zeker als je alleen één box/form gebruikt per pagina. Als je meerdere gebruiken dan heb je dubbel properties op lenses voor die pagina. Ik moet kijken waar WP pagina's meerder infoboxes heeft en wat ze doen met properties die op allebei zitten.

[AlexMekkering]

Ik heb de wijzigingen voor dit issue (r513, r538, r540 & r541) voorlopig terug gedraaid in r542. Hiermee is de functionaliteit rondom weesproperties weer conform de situatie zoals die was, met weesproperties in afgeleide klassen van OWL:Thing dus.

Om in de toekomst verder te gaan met dit issue kan dus als eerste stap r542 terug gedraaid worden om de reeds geïmplementeerde wijzigingen terug te halen, daarmee kan dan verder ontwikkeld worden.

@jheijning, wil jij nog even checken of alles werkt zoals het hoort te werken?

[jbachh]

functionele review r542: FF exporteert weer de volledige TBL props. Alleen worden voor veel props automatische de labes vertaald :-) Heb ik nog niet eerder gezien. Alex had het ook vanmiddag, ik weet niet welke revision hij gebruikte toen.

[LloydRutledge]

Die "vertaling" komt omdat de extract rdfs:labels heeft in meerdere talen. @TeunTheunissen kan je de extract aanpassen zodat er alleen één rdfs:label per URL is en dan alleen in het Engels? Of de default gen uitbreiden om alle gevonden rdfs:labels te prioritiseren met Engel boven aan? Of dan ook de plugin gebruiker een taal volgorde te laten opstellen? De eerste is veel sneller natuurlijk ;)

[TeunTheunissen]

Lloyd, omdat de prioriteit nu verschoven is naar de presentatie en de scriptie kies ik ervoor om de extract aan te passen ;-). Zal daar deze week voor zorgen. Vr. gr. teun

[TeunTheunissen]

TBL extract ontology aangepast. nu alleen met de UK label.