Properties meerdere keren in wiki XML

[jbachh]

In dit fragment van een wiki import log, zie je Property:Foaf:name twee keer voorkomen. Dit komt omdat er meerdere lenzen zijn geselecteerd in de gui met een overlap van attributen.

Dus eigenlijk zou in fresnel2wiki gekeken moeten worden of een Article van een property niet al bestaat in de te exporteren XML vóór het nog een keer toe te voegen ter schaalbaarheid.

[jbachh]

@AlexMekkering review ajb rv455 een hele simpele oplossing

[AlexMekkering]

Goed gezien! 't Zat er schijnbaar al een tijdje zo in, maar meerdere keren dezelfde property Page (over)schrijven is inderdaad enigszins zinloos. Wel doet bij mij dan de vraag rijzen wat er met de ingestelde typen van de properties gebeurt. Deze typen kunnen immers verschillend zijn op verschillende lenzen: op één lens bijv. een Image, op een andere lens bijv. een URL. Kunnen er meerdere This property has type [[Has type:: regels geplaatst worden in een Property: page? Ik denk dat we hier nog even naar moeten kijken.

Vwb de review: Ik ben zo vrij geweest om de ArrayList die je gemaakt had voor het bijhouden van titels van pages om te schrijven naar een situatie waarin de betreffende Articles helemaal niet meer gegenereerd worden. Naast het voordeel dat een gedeelte van de Articles niet meer gemaakt hoeft te worden wil ik als tip nog meegeven dat een ArrayList niet zo geschikt is om te kijken of iets al aanwezig is of niet. De ArrayList wordt bij een .contains namelijk gewoon sequentieel doorlopen totdat het gewenste element gevonden is. In het ergste geval wordt een element niet gevonden en dat wordt pas geconstateerd nadat alle elementen van de lijst bekeken zijn. In dat geval kun je beter bijv. een HashSet gebruiken welke op een veel intelligentere manier (middels een hash van het element) zoekt naar een element in de set waardoor een .contains in nagenoeg constante tijd kan worden uitgevoerd (dus ongeacht het aantal elementen). (zie bijv. http://infotechgems.blogspot.nl/2011/11/java-collections-performance-time.html)

De refactoring heb ik uitgevoerd door de HashMap van namespaces (met soortgelijke performance als de HashSet) te gebruiken om te bepalen of een Property al behandeld is. Hiervoor heb ik, in plaats van de naam van de property, de property (Resource) zelf als key gedefinieerd waardoor ipv slechts de LocalName van die property, de identiteit van de Property zelf bekend is. Het enige wat met deze implementatie anders is, is dat de volgorde van properties bij de smwImport pages niet meer vastligt, maar dat is volgens mij geen probleem.

De wijziging is gecommit in r457. Kijk maar even of je 't er mee eens bent.

[jbachh]

Wat betreft URL en Image: Dat klopt inderdaad, de informatie wat betreft Has type::URL zal niet goed doorkomen, indien de gebruiker deze instellingen op verschillende lenzen wel of niet aanzet. Maar dat probleem geldt nu ook, want als je meerdere properties met dezelfde naam importeert, worden de eerste gewoon overgeschreven door de laatste en is zo ook de info verloren.

Meerdere types per property snijdt geen hout mijns inziens, een test levert op dat als je verschillende types gebruikt in verschillende volgordes, dat type URL in ieder geval voorrang heeft (dus het property krijgt dan type URL). Er bestaat wel type Record, wat zelf uit meerdere typen kan bestaan, maar dat wil je ook niet hebben voor een Image of ExtURL property.

Wat mij het meeste hout lijkt snijden (to make sense en sensible zijn twee woorden die ik continu wil gebruiken, maar de enige goede vertaling is hout snijden, hoewel dat een ongewoon woord is, heb je een betere vertaling, laat het me weten :-)) is om properties die isImage of ExtURL hebben gekregen van de gebruiker in de gui die altijd de oude property page te laten overschrijven, zodat dat de nieuwe standaard wordt? Wat denk jij/denken jullie?

[jbachh]

En wat betreft de arrayList vs HashSet, er begint me weer wat te dagen van de cursus Datastructuren en algoritmes, goed opgemerkt.

r457 ok!

[jbachh]

r474, Alex review alsjeblieft, kleine wijziging zodat properties met isImage/isExternalURL altijd dezelfde property van andere lens overschrijven.

[AlexMekkering]

r474 OK!

Ik laat dit issue nog even open staan totdat er meer duidelijkheid is over #69.

[TeunTheunissen]

om even terug te komen op: 'is om properties die isImage of ExtURL hebben gekregen van de gebruiker in de gui die altijd de oude property page te laten overschrijven, zodat dat de nieuwe standaard wordt? Wat denk jij/denken jullie?'

Ik vraag me af of dit een algemene oplossing is voor het probleem, het is mogelijk dat een property die in de ene lens als image gedefinieerd is in de andere lens als URL getoond wordt.

Een algemene oplossing lijkt mij, zonder te weten of het echt kan, de properties aan de lens te koppelen dus zoiets als: personlens-depiction en humanlens-depiction.

ps. to make sense en sensible zou dat niet vertaald kunnen worden met 'zinnig'?

[LloydRutledge]

Er zijn manieren om de meerdere propertypagina oplossing goed toe te passen. Ja, natuurlijk lens met die naam. Maar dan allemaal met dezelfde import onto en equivalent URI's. En ook met SMW subproperty links van de hoofdpagina voor die property naar als lens-property pagina's ervoor. Die property hoofdpagina moet je dan ook maken natuurlijk. Dan queries op de hoofd property vinden alles instanties met alle lens-properties. De -code legt de annotatie naar de hoofdproperty en niet naar de lens property. Maar die moet een SMW query naar de lens-property sturen om zijn hoofdproperty te krijgen. Dus zoiets als

[[ {{#ask: [[{{{lensProperty|}}} |?hoofdProperty |link=none }}::{{{value|}}} ]]

Die query moet je test, natuurlijk, en vast wat debuggen.

[jbachh]

Lloyd en Teun, dat klinkt interessant, we gaan het er met het team i.i.g. over hebben zondag, en misschien ook even bij de Scrum.

en zinnig, dat snijdt hout inderdaad als vertaling!

[jbachh]

@LloydRutledge In #70 geef je aan de je "wees" properties liever wilt vermijden. Als dat lukt, dan zou het op de GUI maar op één plek mogelijk zijn voor de gebruiker om met de rechtermuisknop en dan "change type" de type van een property naar ExtURL of Image te wijzigen. Op dit moment is het in onze plugin ook zo geïmplementeerd dat als een gebruiker in één lens met change type een property naar Image of ExtURL wijzigt dit dan geldt voor alle lenzen. Dus de logica is precies hetzelfde in alle twee de gevallen.

Als de weesproperties verdwijnen heeft de oplossing met bijvoorbeeld subprop PersonLens-foaf-depiction en een hoofdprop foaf-depiction dan geen enkele waarde meer, omdat de foaf-depiction maar in één lens voor gaat komen in de GUI. Betekend het dan niet het overbodig en niet nodig is om het laatste te doen?

[jbachh]

(Op dit moment is het dus al geïmplementeerd dat als een gebruiker in Thing foaf:depiction een image maakt, dat dit dan ook geldt voor foaf:depiction in Person)

[LloydRutledge]

Ik wil wees properties niet vermijden. Ik wil dat ze alleen in de owl:Thing box komen. En niet meer in alle boxes. En met een algoritme ook recursief door de hele hierarchy, zodat als een hele subtree domain is van de property, dat alleen lens van de root van de tree die property krijgt ... in die tree. Maar het kan nog dat een property meerdere, aparte subtrees (of bladeren) als domain heeft. En die property komt dan op meerdere lenses. En die ene property kan dan aparte Fresnel types hebben in de aparte lenses. En gebruikers kunnen dat willen. En de combinatie lens-property property pagina's blijven een oplossing ervoor. Klopt dit?

[jbachh]

Zinnig wat je hierboven zegt Lloyd. Heb het zo geïmplementeerd.

Zie http://abiteam30.lukylx.org:3080/mediawiki/index.php/Property:Foaf-name . Dit is de hoofdpropertypagina en deze laat de subprops zien op de pagina.

Alex, review ajb. Wel het één en ander gewijzigd, in principe is het eenvoudiger geworden, daar gewoon van alle subproperties pagina's gemaakt worden en één keer voor de superprop.

[AlexMekkering]

Code ziet er goed uit en de output in MediaWiki ook. Het is inderdaad weer wat eenvoudiger geworden.