Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OWL-lite cardinality <=> 0/1 #47

Closed
LloydRutledge opened this issue Jan 29, 2015 · 34 comments
Closed

OWL-lite cardinality <=> 0/1 #47

LloydRutledge opened this issue Jan 29, 2015 · 34 comments

Comments

@LloydRutledge
Copy link
Contributor

Implementeer a.u.b. de cardinaliteit die in de OWL dialecten behalve OWL Full zit. Dus min, max en gewoon cardinaliteit met allen 0 en 1 als waarden. Milestone is Forms omdat het nodig voor de TBL scenario lijkt. Assignee lijkt me Teun omdat het moet met de onto beginnen. En dan tegelijketijd:

  • Joop voert het in in fresnel2wiki
  • Teun maakt de default owf-fresnel
  • Alex zet het in de GUI

Deze rijen in de tabel in https://svnext.ou.nl/INF_Studenten_ABI_team30/source/trunk/FresnelForms/design/OWFdev.xlsx zijn dus rood.

@LloydRutledge
Copy link
Contributor Author

booleans isList en isMandatory

@TeunTheunissen
Copy link
Member

Issue is opgelost in revisie 371, Joop graag reviewen.

@AlexMekkering
Copy link
Member

Eigenlijk dienen alle commits aan branches/Teun/MandatoryMultiValue gereviewed te worden (r364, r365, r367, r368, r370 & r371)

@TeunTheunissen, Wellicht is het handig om, wanneer je denkt dat het goed is en het goed bouwt incl. unit-tests, branches/Teun/MandatoryMultiValue te mergen met trunk zodat Joop de resulterende commit daaruit in één keer kan reviewen (dan hoeft Joop ook geen switch te doen naar de branch en weer terug naar trunk).

@TeunTheunissen
Copy link
Member

Alex, ik heb in eerste instantie ontwikkeld in de branch, maar bij een update was de trunk ook aangepast. Ik heb daarna verder ontwikkeld in de trunk, die is dus uptodate, Joop hoeft zover ik kan overzien niet te switchen en kan de laatste revisie van de trunk reviewen.
Tot mijn schande moet ik bekennen dat er nog geen unittests zijn, ik zal daar nog wat aan doen.

@TeunTheunissen
Copy link
Member

@AlexMekkering Wellicht kunnen we het zondag nog eens hebben over subversion

@AlexMekkering
Copy link
Member

De branch is niet gemerged met de trunk, dus Joop zal je wijzigingen niet zien in de trunk, zie:
image

Zie voor meer info over het mergen bijv. https://svnext.ou.nl/INF_Studenten_ABI_team30/Environment%20&%20Misc/Resources/Subversion/TortoiseSVN-1.8.8-nl.pdf hoofdstuk 4.20.2.

@TeunTheunissen
Copy link
Member

Dank, hoofdstuk gelezen en een merge uitgevoerd. We kunnen het er vanmiddag over hebben.

@jbachh
Copy link
Contributor

jbachh commented Feb 22, 2015

Review goed! Ik heb nog even de vrijheid genomen om de naamgeving in de gui te normaliseren: AutoComplete, Singlevalue en multiValue wordt Auto complete, Single value en Multi value, staat uniform net wat netter samen met Hide label, Change type, etc. zie mijn commit die later komt vanavond (review niet nodig).

@AlexMekkering
Copy link
Member

Implementatie was nog niet compleet: de attributen owf:isList en owf:isMandatory werden niet verwerkt bij het inlezen van een fresnel bestand (load Fresnel).
Ik heb de aanpassingen hiervoor gecommit in r412.

@TeunTheunissen please review.

@TeunTheunissen
Copy link
Member

@LloydRutledge De implementatie heeft een vaste default voor de waarden van IsList (true) en Mandatory (false). Deze waarden worden niet geinitialiseerd vanuit de ontology, was dat wel de bedoeling? Ik heb de dbpedia ontology nagezocht en er wordt nergens een cardinaliteit gedefinieerd.

@LloydRutledge
Copy link
Contributor Author

@TeunTheunissen Ja, dat klopt waarschijnlijk. Cardinaliteit is leerzaam en interessant in class maar buiten RDFS-plus een dus iets gevaarlijk in het praktijk, en dus lang niet altijd gebruikt waar het conceptueel toch van toepassing zou zijn. Fresnel2wiki werkt ermee, toch? De aanpak voor de paper lijkt dat ik de opgeslagen Fresnel code edit met de bijhorende Fresnel-OWF triples en dan terug in de plugin zetten en dan de wiki maken. Moet dat werken? Voor de paper is dat prima.

@AlexMekkering ik neem aan dat de GUI niks heeft om die direct om aan te passen.

Een minder goed alternatief is om de DBPedia ontologie uit te breiden met OWF cardinaliteit op die properties. Direct op de DBP properties kan maar dan is het meer netjes als je subproperties ervan maken. Maar dan hoe krijg je die aan de lens? En dan ben je een onto aan het maken alleen om de interface te krijgen.

@AlexMekkering
Copy link
Member

De GUI heeft wel een manier om (indirect) de cardinaliteit voor een Property in te stellen, nl:

  • Met optie 'Single value' of 'Multi value' (default) kan aangegeven worden of de max cardinaliteit 1 of oneindig is. Eigenlijk dus of iets een lijst wordt in SMW of een enkel element.
  • Met optie 'Mandatory' of 'Optional' (default) kan aangegeven worden of de min cardinaliteit 1 of 0 is.

Bedoel je dit?

@TeunTheunissen
Copy link
Member

@lloyd, zoals Alex het beschrijft werkt het. Je kan dus met de Gui de owf style properties isList en isMandatory instellen en daarna meteen de wiki code genereren. Er hoeft niet geedit te worden buiten de plugin om.

@LloydRutledge
Copy link
Contributor Author

De GUI interface ervoor is goed. Met aardig verrassingen!

Maar ik krijg default gedrag niet. Noch in de GUI noch de opgeslagen Fresnel noch in de opgeslagen wikicode. Minstens niet met mijn test onto van de link hieronder.

Werkt default generator van Mandatory en geen list uit andere test ontologieën, of uit bepaalde OWL construct patronen?

De code zit op https://svnext.ou.nl/INF_Studenten_ABI_team30/Environment%20&%20Misc/Test/testInOnto.n3

De weergave van default de Frensel GUI is:

knipsel

Die wel met twee dataproperties op een test class. En die test class subclasst naar property min/max 1 restrictions. Maar er is geen _ of + bij de properties in de box. En de pulldown toont ook niet mandatory en list.

@TeunTheunissen
Copy link
Member

Een test hier levert op:
dropdown
Dit is het dropdown menu als je met de rechtermuis op een attribuut klik.
Nadat zowel 'single value' en 'Mandatory' is aangeklikt worden de suffixes achter het attribuut getoond.
suffix_tags

Dit is getest met de plugin release 1.0.11

@LloydRutledge
Copy link
Contributor Author

Klopt, Teun. Met de GUI kan je mandatory aan en list uitzetten. Komt goed in de paper, Als dat ook via default kan van card <=> 1 wordt het ook leuk in de paper.

@TeunTheunissen
Copy link
Member

Hallo Alex, Joop,

Ik heb onze plugin aangepast zodat de multivalue/singlevalue en mandatory property's uit de data ontology gelezen worden.
De branch 'branches\teun\MandatoryMultiValue_OWLAPI' waarin ik ontwikkeld heb is nu gemerged met de trunk,
@AlexMekkering zou je willen controleren of dat goed gegaan is.
In de map 'Environment & Misc\Ontologies\WorkingOntologist' heb ik de ontology
'JeamesDeanMovies.owl' toegevoegd.
Deze ontology bevat een max en een min restrictie en is gebruikt om te testen.
Ik heb nog geen testcase aangemaakt dat zal vanavond gebeuren.

@AlexMekkering graag een review

@AlexMekkering
Copy link
Member

De merge is helemaal goed gegaan, ik wacht voor de testen je unit tests nog even af.
Ik heb al wel een paar refactorings doorgevoerd nav de codereview. Hiervoor hoef je dus zelf niets meer te doen. Het volgende heb ik aangepast:

  • In r462 heb ik de min- en max cardinaliteits-functies en attributen ge-'pull-up't naar de basisklasse Property, omdat ze voor alle soorten properties hetzelfde geimplementeerd waren. Gelukkig is dit één actie in Eclipse (Refactor->Pull up...), dus het was niet zo lastig 😉
  • Vervolgens heb ik in r463 ook voor de PropertyBinding verwezen naar die ene basisklasse Property waardoor de code (welke twee keer hetzelfde deed) gehalveerd kon worden.
  • Als laatste heb ik in r464 de System.out.println statements vervangen door logging statements waardoor beter geconfigureerd kan worden wat er allemaal getoond moet worden.

De afronding van de review volgt na het toevoegen van de testen.

@TeunTheunissen
Copy link
Member

Mooi dat de merge goed gegaan is. Dank voor de refactorings.
Ik heb de classe CardinalityTest toegevoegd aan de unit testen. De ontology JeamesDeanMovies.owl is toegevoegd aan de resources. Deze ontology heeft min en max cardinaliteiten gedefinieerd op de property ownsmovie voor de classe onemovieowner.

Ik heb aan de classe ontology de methode findClass() toegevoegd die een classe zoekt op basis van de uri. De methode findProperty() is toegevoegd aan de classe Class en zoekt de property op basis van de opgegeven uri.
@AlexMekkering graag weer reviewen.

Vr.gr. Teun

@AlexMekkering
Copy link
Member

@TeunTheunissen, na het reviewen van de unit test heb ik de volgende opmerkingen:

  • De unit test behandelt slechts de 'happy flow', dus er worden geen combinaties van min- en max-cardinalities getest.
  • Om de code te kunnen testen heb ik een paar andere movieowner klassen aan de ontologie toegevoegd in r487.
  • Wanneer je een klasse zonder min- of maxcardinality gebruikt ontstaat er in OwlImport een index out of bounds error tht regel 487 & 506 tgv het feit dat findOWLObjectProperty dan index -1 teruggeeft.
  • In de unit tests gebruik je ontology.findClass terwijl je dat ook aan de betreffende lens kunt vragen (lens.getClassLensDomain()). Op die manier hoef je de ontologie niet meer te doorzoeken.
  • je gebruikt vervolgens class.findProperty() terwijl je dat ook aan de property van de betreffende propertyBinding kunt vragen propertyBinding.getProperty().getProperty(). Op die manier hoef je de properties voor een klasse niet meer te doorzoeken.
  • nadat ik zelf wat heb proberen te testen, denk ik dat er wellicht nog een denkfout zit in de omgang met cardinaliteiten zit. Het volgende is namelijk het geval:

Een property kan voor meerdere klassen gedefinieerd zijn. De cardinaliteit geldt volgens mij daarom niet voor een property zelf, maar voor een property voor een specifieke klasse: je kunt niet spreken van de cardinaliteit van een property, wanneer je de klasse niet weet waar de cardinaliteit van die property voor geldt. Dit zie je ook terug in de manier waaarop het binnen de ontologie gedefinieerd is: de restriction geldt voor de combinatie van klasse en property (gedefinieerd door owl:onProperty en owl:onClass).

Wat vind jij?

@TeunTheunissen
Copy link
Member

Dank voor de review ik ga deze punten oplossen.
Wat de denkfout betreft ben ik van de situatie uitgegaan die jij beschrijft, een restrictie voor een property wordt gekoppeld aan de lens waar de property betrekking op heeft.
Ik zal de code nog eens bekijken aan de hand van de aangepaste ontology JeamesDeanMovies.owl.
Bedankt voor de moeite. vr.gr. Teun

@AlexMekkering
Copy link
Member

Maar voor de property zelf worden de min- en maxcardinality gezet, er is geen onderscheid voor dezelfde property voor verschillende klassen, dus er kan maar één definitie zijn (de min- en max-cardinality van de ontology.Property). Zal dan niet voor elke lens waar die property op gedefinieerd is, de isList en isMandatory eigenschappen hetzelfde gedaan worden?
Volgens mij zal dan voor bijv. alle soorten movieowners de isList en isMandatory velden gelijk zijn, wat niet de bedoeling is.

@TeunTheunissen
Copy link
Member

In de package 'nl.ou.fresnelforms.ontology' heeft de Property classe de attributen mincardinality en maxcardinality. deze classe wordt geinstantieerd in een array in de classe 'Class' hiermee zijn de cardinaliteiten gedefinieerd voor propties van een bepaalde classe.

In de nl.ou.fresnelforms.fresnel worden de attributen 'isList' en 'mandatory' geinstantieerd in een proeprtybinding array in de lens classe. Dus hiermee is ook de link tussen lens en property eigenschappen vastgelegd.

De fresnel code die gegenereerd wordt zijn de 'islist' en 'ismandatory' gekoppeld aan een enkel attribuut via de format definitie van dat attribuut. zie hieronder voor de james-dean ontology:
:OneMovieOwnerLens a fresnel:Lens ;
fresnel:showProperties ( _:b0 ) .

_:b0 a fresnel:propertyDescription ;
fresnel:property untitled-ontology-432:ownsMovie ;
fresnel:use :ownsMovieOneMovieOwnerLensFormat .

:ownsMovieOneMovieOwnerLensFormat
a fresnel:Format ;
owf:isList false ;
owf:isMandatory true ;
fresnel:label "ownsMovie" .

Zover ik kan overzien zijn de cardinaliteiten gekoppeld aan properties van classe of lensen.
Zie ik iets over het hoofd?

@TeunTheunissen
Copy link
Member

Ik heb de james dean ontology uitgebreid met wat verschillende klassen en zie nu dat ze alle dezelfde islist en mandatory properties hebben staan....

@AlexMekkering
Copy link
Member

Volgens mij ben je trouwens nog een bestand vergeten te mergen (of committen) met trunk, nl. PropertyLabelAlphabetComparator in package nl.ou.fresnelforms.view.

@AlexMekkering
Copy link
Member

Ik heb nog even naar je verhaal over de instantiatie van de properties gekeken en volgens mij zit het als volgt:

  • de Property objecten worden binnen de nl.ou.fresnelforms.ontology.Class klasse inderdaad geregistreerd in ofwel de ArrayList dataProperties, ofwel de ArrayList objectProperties.
  • De nl.ou.fresnelforms.ontology.Class klasse instantieert de objecten echter zelf niet. De objecten worden namelijk toegevoegd middels de public methods addDataProperty en addObjectProperty waaraan de te registreren property als argument dient te worden meegegeven.
  • De public static methoden nl.ou.fresnelforms.main.OWLImport.matchDataPropertiesWithClasses en nl.ou.fresnelforms.main.OWLImport.matchObjectPropertiesWithClasses (via addProperty2DomainClasses) worden gebruikt om de addDataProperty en addObjectProperty methoden aan te roepen met de properties die OWLImport verzameld heeft.
  • OWLImport verzamelt de object- en dataproperties vanuit de bronontologie in methoden findDataProperties en findObjectProperties. Dit is ook waar de instantiatie van de properties plaatsvindt: voor elke relevante data- en objectProperty in de bronontologie wordt een overeenkomstig object aangemaakt in de nl.ou.fresnelforms.ontology package.
  • Middels de OWLOntology methoden getDataPropertiesInSignature() en getObjectPropertiesInSignature() worden echter, los van eventuele relaties met klassen waarin ze gebruikt worden, properties teruggegeven.

Mijn conclusie is daarom dat een specifieke Property object, of dat nu in 0, 1 of 100 klassen gebruikt wordt, slechts eenmaal geinstantieerd wordt. Wanneer je daaraan vervolgens min-en maxcardinality velden toevoegt, zullen deze voor elke property/klasse combinatie voor een property hetzelfde zijn omdat vanuit een willekeurige klasse waar die property voor geldt, telkens verwezen wordt naar dat ene Property-object.

Dit gedrag lijkt me trouwens wel in lijn met hoe Properties en Classes gedefinieerd zijn binnen RDFS.

De PropertyBinding binnen de nl.ou.fresnelforms.fresnel package representeert een relatie tussen een property en een class (eigenlijk die tussen een property en een Lens), dus die isList en mandatory zijn daar wel op hun plaats.
Er zal dus mijns inziens denk ik een klasse tussen moeten komen binnen de nl.ou.fresnelforms.ontology package die de relatie tussen property en class beschrijft (inclusief min- en maxcardinality).

@TeunTheunissen
Copy link
Member

De classe PropertyLabelAlphabetComparator is toegevoegd aan de repository.

@TeunTheunissen
Copy link
Member

Alex, ik heb de code nog eens doorgelopen en ben het helemaal met je eens, er wordt verwezen naar een en hetzelfde property object.
In plaats van een extra klasse dacht ik eraan om het property object van een clone constructor te voorzien zodat er wel degelijk aparte properties worden geinstantieerd per classe. De bestaande code hoeft dan niet aangepast te worden zover ik kan overzien ;-).

@TeunTheunissen
Copy link
Member

Nog eens de code bekeken, een clone constructor is geen best idee, er wordt teveel dubbel opgeslagen. Ik denk ook dat we moeten gaan voor een extra klasse.
ps de structuur zoals die is gedefinieerd ondersteund inderdaad de RDFS standaard.maar niet de OWL uitbreidingen.

@LloydRutledge
Copy link
Contributor Author

@AlexMekkering, die zijn goede punten over de context en "range" van een cardinality restriction. De cardinality OWL properties vallen altijd in een owl:Restriction die ook altijd een owl:onProperty class heeft. Ja, geen owl:onClass property. Maar owl:Restriction bepaalde een class. En dan meestal als object in een subClassOf of equivalent property voor een al benoemde class. Zo schrijft Protégé cardinality op in OWL. En die restrictions zijn dan op de combinaties van property en class. En snel opstelling via Protégé geeft:

<owl:Class rdf:about="http://www.semanticweb.org/lru/ontologies/2015/2/untitled-ontology-170#TestClass">
    <rdfs:subClassOf>
        <owl:Restriction>
            <owl:onProperty rdf:resource="&owl;topDataProperty"/>
            <owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minQualifiedCardinality>
            <owl:onDataRange rdf:resource="&owl;rational"/>
        </owl:Restriction>
    </rdfs:subClassOf>
</owl:Class>

@TeunTheunissen, is deze het patroon dat de default Fresnel-OWL generator zoekt? En zet ie dan de mandatory en/of list (of default niet) in alleen de Form voor die ene class?

@TeunTheunissen
Copy link
Member

@LloydRutledge Yep, er wordt gezocht naar restrictions voor een classe waarbij gekeken wordt naar equivalente en naar subclasses. Daarna wordt gefilterd op min en maxcardinaliteit. Vervolgens wordt de min/max cardinaliteit toegkend aan de juiste property. Dit gaat veranderen zodat de min en max cardinaliteit toegekend wordt aan classe in combinatie met de property.

@TeunTheunissen
Copy link
Member

De cardinalities zijn nu geimplementeerd per classe dmv de classe PropertyRestriction. De james Dean ontology is uitgebreid met de combinaties die mogelijk zijn met islist en ismandatory, 4 dus. De unittest is aangepast. @AlexMekkering graag reviewen.

@AlexMekkering
Copy link
Member

Review OK. Ik het gevoel dat het wat simpeler kan (er is sprake van duplicate code), maar functioneel gezien is het helemaal correct. De unit tests zijn ook netjes en volledig uitgevoerd, dus 👍

Ik heb nog even wat checkstyle meldingen opgelost in r494.

@TeunTheunissen, wil jij OWFdev.xlsx in de design map hiervoor nog even up-to-date maken?

@TeunTheunissen
Copy link
Member

Ik heb de duplicate code gezien maar kon geen mooie oplossing ervoor bedenken dus heb ik het zo maar laten staan. Dank voor de checkstyle meldingen. De OWFdev.xlsx sheet is aangepast.
Ik sluit dit issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants