TBL RDF Export neemt sommige properties niet mee

[jbachh]

Dit zijn de properties die meegenomen worden:

Dat zijn dus lang niet allen. Ze zijn wel gewoon geïmporteerd net als alle anderen en op de property pagina's kan ik geen enkel verschil vinden met de anderen. Ook heeft het niet te maken met de nameSpace, of het type van de property (die komen verschillend voor) Wat wel apart is, is dat SMW geen link naar Pages using the property geeft bij properties die niet worden geëxporteerd. Zie het verschil:


Zie ook op de special:Properties pagina:

Ik zou niet weten hoe dit op te lossen, maar hier zal het probleem met exporteren liggen. Wat frappant is, dat dezelfde properties die wél meegenomen worden, de properties zijn die in fresnel anoniem zijn en vice versa. Zie hieronder (caption wordt niet meegenomen, parent wel):

Hebben jullie enig idee? @AlexMekkering @TeunTheunissen ?

[AlexMekkering]

Ik heb er gisteravond ook nog even naar gekeken en kon zo inderdaad ook geen afwijkingen vinden in wat we importeren (anders dan dat we duplicate Property pages niet meer importeren).

Ik denk dat het probleem gezocht moet worden in hoe SMW bepaalt welke Properties waar gebruikt worden, ik denk dat het exporteren van de RDF daar weer naar kijkt namelijk.
Dit bracht mij tot de volgende opties om verder te onderzoeken:

• Maakt de volgorde uit waarin properties worden geïmporteerd? Misschien wordt een pagina slechts herkend als gebruiker van een Property wanneer deze later (of juist eerder) gecreëerd is? Misschien dat dan het afdwingen van een andere volgorde in de xml export een oplossing is.
• Is er een compatibiliteits-issue met properties met speciale tekens? We hebben met het invoeren van namespace prefixes een dash (-) en mogelijk andere extra tekens aangeleverd (in het geval van owf_style_tim_berners_lee een underscore). Misschien is dan een andere normalisatie van geprefixte properties de oplossing.

Ik kom vanavond pas weer toe aan verdere analyse (en mogelijke oplossingen) mar dit zijn mijn ideeën.

[jbachh]

-Volgorde: wie weet, maar ik betwijfel het, daar foaf-name als één van de eerste wordt geïmporteerd, birthName als één van de laatste, maar allebei worden niet herkend in SMW als exportable, of als linkable (pages using this property).
-speciale tekens: ik zie geen verschil tussen tekens in BirthName en BirthPlace.. maar het is ook wel bijzonder dat RDF Export het eerst wel deed, en nu niet meer sinds de laatste wijzigingen, dus..

Het meest frappant m.i. is dat juist de anonieme props het wel doen en de niet anonieme niet. Wat voor effect heeft dat op de wiki? En wat voor effect in verband met de laatste wijzigingen?

[jbachh]

p.s. Hopelijk vind je de oplossing vanavond, zo niet dan ga ik er morgen ook weer mee verder..

pps: op (ik geloof) de semantic mediawiki website staat wel het één en ander over "verboden" tekens, bijvoorbeeld dat een - niet het eerste karakter mag zijn (wordt gebruikt voor inverse props). heb even gezocht maar kan de pagina niet zo snel terug vinden.

[TeunTheunissen]

Hallo Joop, ik heb er even naar gekeken maar heb geen opties waarom de website en occupation niet geexporteerd worden.
Moet nu even eten.
Teun

[AlexMekkering]

@jheijning schreef:
Wat frappant is, dat dezelfde properties die wél meegenomen worden, de properties zijn die in fresnel anoniem zijn en vice versa.

Het komt er dus op neer dat alleen de properties die niet in een andere lens aanwezig zijn, correct geëxporteerd worden. Laat dit nu precies de properties zijn voor welke geen duplicate property pages zijn weggelaten.

Mijn redenering hierbij is als volgt:

• Slechts voor de Person lens zijn de properties (welke getoond moeten worden) gestyled en dus per definitie anoniem omdat er een specifiek Format voor is gemaakt (Er is dus een fresnel:propertydescription voor die property welke het specifieke Format ervoor definieert).
• Slechts voor de properties die ook in andere lenzen gedefinieerd zijn (bijv. foaf:name) is er inderdaad meer dan één definitie van hoe die getoond moet worden, nl. de standaard definitie van die van elk van de overige lenzen, plus de specifieke definitie van de PersonLens. Voor deze properties zijn dus in het verleden per definitie meerdere malen Property pages gedefinieerd. In de nieuwe situatie is dat hooguit 1 + elke keer dat een lens de property als image of external url gedefinieerd heeft.

Voor de rest constateer ik dat er voor de properties welke ook op andere lenzen gedefinieerd zijn, templates bestaan waarvoor geen pages gemaakt zijn die er gebruik van maken, misschien dat dit er nog iets mee te maken kan hebben. Voor mij lijkt het nu te maken te hebben met zowel #64 als #68.

Ik heb vanavond het volgende gedaan om deze bug te onderzoeken, allen zonder succesvolle uitkomst:

• Properties hernoemd om vreemde tekens uit te sluiten.
• Templates verwijderd om 'dangling links' uit te sluiten.
• Voor de huidige situatie (dus met prefixed properties) heb ik alle property pages (dus ook duplicaten) geïmporteerd.
• De situatie ten tijde van r413 (die xml staat nog in svn 😄) opnieuw geïmporteerd (dus zonder prefixes en met duplicaten), en een Tim_Berners_Lee_OLD pagina aangemaakt om de properties daadwerkelijk te gebruiken.

Kortom... I'm lost too, en ik vraag me af of het ooit helemaal correct gewerkt heeft en zo ja, wanneer was dat nog? Misschien kunnen we zo proberen te achterhalen waar het fout ging.
Hoe dan ook lijkt me dit een probleem wat wel eens diep in SMW verzonken zou kunnen liggen, een gemeenschappelijke conditie waardoor SMW beslist om die Property als 'niet gebruikt' te verklaren. Een goede kandidaat ervoor lijkt me de templates waar de properties op gedefinieerd zijn, maar welk verder niet gebruikt worden. Wellicht ben ik nog een template vergeten weg te gooien, of is weggooien niet voldoende???

To be continued...

[jbachh]

Het heeft wel gewerkt. Zie ook http://abiteam30.lukylx.org:3080/mediawiki/index.php/Property:Name deze laat gewoon de pagina's zien die de property gebruikt. En in dat geval zal de RDF Export zeker ook werken.

Goed werk, morgen kijk ik ook verder.

[jbachh]

hmm ok, dit zou wel heel "frappant" kunnen zijn: ik had property:name even blank gemaakt. en toen liet ie nog maar één pagina als verwijzing zien. Toen rollback, toen liet er twee zien. En voordat ik die twee acties uitvoerde liet ie er wel 5 zien...

dus zou het zo kunnen zijn dat Semantic MediaWiki gewoon nog niet klaar was doorzoeken van de hele ontologie om de verwijzingen te maken? en dat daardoor de RDF export niet werkt?

zie ook http://abiteam30.lukylx.org:3080/mediawiki/index.php/Special:SMWAdmin

Ps: zal trouwens wel niet.. want de oude TBL gebruikt property:name.. ik zal morgen nog eens nakijken hoe de export eigenlijk werkt, en er een documentje bij schrijven..

[TeunTheunissen]

Googlen op dit probleem leverde op:
De help van SMW gaf voor "Why doesn't data I have just added show up in queries?" de oplossing om de cache uit te schakelen, verwacht niet dat het relevant is maar het zou kunnen.

How do I completely disable caching?
Add in your LocalSettings.php file the following lines:
$wgEnableParserCache = false;
$wgCachePages = false;

[jbachh]

TimTestRDF exporteert nu ook de BirthName! En birthName verwijst ook naar die pagina, dus hopelijk betekent dit dat het niet aan onze export ligt.

Ik heb ook data repair en upgrade aangezet http://abiteam30.lukylx.org:3080/mediawiki/index.php/Special:SMWAdmin vanavond kijk ik verder..

[TeunTheunissen]

Bij mij werd birthname al geexporteerd maar de property 'occupation' en 'website' niet. Hebben jullie die property's wel in de export staan?

[jbachh]

TimTestRDF exporteert nu al zijn properties, Tim_Berners_Lee_OLD nog geen verbetering

[TeunTheunissen]

Joop, ik zie dat je bij TimTestRDF de label hebt laten vervallen, ik heb daar nog naar gekeken maar het leek mij dat het alleen om de opmaak ging gewoon tekst i.p.v. een hyperlink. Hoe heb je de labels laten vervallen?

[jbachh]

Hoe bedoel je? De labels staan toch gewoon aan de linkerkant boven de values? Dit is nog een hele oude pagina van vóór de verandering van tabel naar div's. Ik zie nu trouwens dat de property depiction ook hier niet geëxporteerd wordt. (name, birthName, en de rest wel)..

[jbachh]

Ik heb trouwens toegevoegd wat Teun gevonden had aan localSettings (cache is niet nodig voor kleine wikis)

How do I completely disable caching?
Add in your LocalSettings.php file the following lines:
$wgEnableParserCache = false;
$wgCachePages = false;

[jbachh]

haha, ik gebruik onze plugin om opnieuw tim berners lee te importeren met special: import (ik heb alle lenzen waarnaar verwezen wordt vanuit lens Person ook ge-show- ed) ben nog vergeten om depiction en homepage change type te doen.. ik kijk direct naar de RDF export, er wordt niets geëxporteerd. Een minuut later kijk ik weer, en nu worden ALLE properties direct geëxporteerd! Wie weet dat die disable caching het effect heeft gehad?

Toen heb ik die disable caching weer verwijdert uit de local Settings.. Een aantal pagina's uit geblanked. en weer geïmporteerd. En hij RDF export doet het nog steeds prima..

http://abiteam30.lukylx.org:3080/mediawiki/index.php/Special:ExportRDF

Data repair and upgrade stond aan trouwens (20%) op http://abiteam30.lukylx.org:3080/mediawiki/index.php/Special:SMWAdmin

Dus ik snap het nog steeds niet, maar in ieder geval geeft exportRDF het goede resultaat..

[jbachh]

@LloydRutledge Ik heb de oorzaak gevonden van de issue (zie openingspost): special:ExportRDF heeft de arraymapfunctie nodig om de properties te vinden.
Nu wordt foaf-name niet geëxporteerd (zie de value div):

en nu wel:

Voor images kunnen we sowieso geen arraymapfunctie gebruiken, want we hebben dan een element nodig, en ook voor external URL's, als we de semantische verwijzing uitgummen om de kleur blauw te houden in de link op de ibox, werkt de export niet:

De enige manier die ik kan bedenken om al deze functionaliteit te houden, en toch de volledige RDFExport te krijgen, is om een dummy-div te maken voor de export, met display:none:

Dit is niet heel elegant, maar het werkt wel. Is deze oplossing acceptabel?

[LloydRutledge]

@jheijning lijkt me prima. Het is alleen niet elegant in de wikipagina-code, toch? Wat de gebruiker ziet blijft elegant lijkt het.

[jbachh]

Ik heb de dummy div toegevoegd. Dit heeft geen invloed op wat de gebruiker ziet, alleen in wikicode.

Teun, review ajb.

[AlexMekkering]

Dit lijkt me niet echt de oplossing, ik denk dat het puur toeval is dat het met die arraymap in dit geval werkt. Mijn redenatie is als volgt:

• De RDFExport functionaliteit is gedefinieerd in de Semantic MediaWiki extension.
• De #arraymap parser function is gedefinieerd in de Semantic Forms extension.
• Hoewel Semantic Forms afhankelijk is van Semantic MediaWiki, is dit andersom niet het geval. Maw, Semantic MediaWiki kan ook zonder Semantic Forms gebruikt worden.

Omdat Semantic MediaWiki ook zonder Semantic Forms werkt, kan het voor de RDFExport functionaliteit niet afhankelijk zijn van of Semantic Forms elementen wel of niet gedefinieerd zijn in een template, dus moet het waargenomen gedrag het gevolg zijn van iets wat niet puur Semantic Forms gerelateerd is.
Ik denk eerder dat óf de Semantic MediaWiki database niet goed bijgewerkt wordt, óf het caching-mechanisme nog roet in het eten gooit.

Ik stel daarom voor dat we de gemaakte wijzigingen hiervoor weer terugdraaien totdat we een beter gevoel hebben van wat dit veroorzaakt kan hebben.

[jbachh]

Goed gezien! Het is inderdaad niet specifiek de arraymap functie, het is de expliciete semantische link die in die functie zit, bijvoorbeeld: [[Person-foaf-depiction::{{{Person-foaf-depiction}}}]] . Dit snijdt ook hout en zo heeft de oplossing ook geen afhankelijkheid van semantic Forms.

Dus ik laat de dummy div gewoon staan, met alleen de link ipv de hele arraymap functie. bijv:

[[Person-foaf-depiction::{{{Person-foaf-depiction}}}]]

. Heb het getest en correct bevonden.

Ik denk dat we dus verder niet hoeven te onderzoeken en de server opnieuw hoeven te installeren om voor bugs te checken. Dus de oplossing blijft in principe gewoon hetzelfde (minus arraymap), Teun review alsjeblieft. (r505)

[AlexMekkering]

Aaah, nu wordt het mij ook duidelijk! Omdat de infobox properties voor niet-links geen semantische property verwijzing kregen, werden ze natuurlijk ook niet aangemerkt als zijnde een Property.
Is het dan niet beter om in de template per definitie voor elke property een semantische koppeling te maken ([[::]])? Als het goed is, zal de Property page van de betreffende properties dan bepalen of iets een link wordt ([[Has type::Page]] en [[Has type::URL]]) of niet (de andere typen). Alleen voor images zal dan denk ik deze constructie nog gebruikt moeten worden omdat de Property verwijzing niet goed ging binnen de img-tag toch?

[LloydRutledge]

Werkt het nog als iemand meerdere depictions voor op één form invult? Dan moet de box template toch ieder depiction URI als property toekennen via [[Person-foaf-depiction::]] én die weergeven als een verbeelding. Dus met een list krijg je meerdere keer [[Person-foaf-depiction::]] en eigenlijk meerdere plaatjes na elkaar. Werkt het zo nu? Lijkt me dat het zo hoort.

Alex, ik deel je zorg niet over wiki's zonder Forms. Volgens mij kunnen we wél aannemen dat alle wiki's die een FForms export importeren Semantic Forms hebben. Anders is veel van de import zinloos. Dus kunnen we aannemen dat arraymaps werkt. Of mis ik iets?

[AlexMekkering]

Ik weet niet of de depictions nu in een list werken, maar ik ben het met je eens dat dat zou moeten kunnen. Ik denk dat het dan genoeg is om zowel de dummy 'display:none' div als de img tag door een #arraymap te omhullen. Joop kan jij checken of dat er zo inzit?

Vwb mijn opmerkingen eerder: dat was niet echt een zorg, maar meer een opmerking voor het feit dat het toevoegen van een #arraymap parser function als oplossing werd gezien voor de ontbrekende RDF export properties. Mijn punt was dat een #arraymap alleen niet de oplossing kon zijn omdat deze parser functie in Semantic Forms gedefinieerd is en de RDFExport functionaliteit in Semantic Mediawiki, terwijl Semantic Mediawiki geen afhankelijkheden heeft met Semantic Forms (Wel andersom). Natuurlijk mogen we ervan uitgaan dat Semantic Forms is geinstalleerd, maar het standaard gebruik ervan in dummy velden lijkt me niet veel toe te voegen.

Zoals Joop heeft laten zien, blijkt de oplossing inderdaad te liggen in het toevoegen van een dummy property verwijzing ([[::]]) ipv het feit dat een arraylist wordt toegevoegd. Dit lijkt me ook meer logisch omdat dit wel een Semantic MediaWiki feature betreft.

In mijn laatste opmerking stel ik dat de dummy properties eigenlijk helemaal niet nodig zouden zijn als de property verwijzingen consequent voor elke property zijn gedefinieerd en het wel of niet tonen van een link bepaald kan worden met een [[Has type::...]] property op de Property page ervoor.

[jbachh]

Meerdere depictions in een list:

In code ziet dat er zo uit:

Dan krijg je wel het URL-link symbooltje rechts van de foto, zie:

en als je in het formulier 2 urls in geeft als depiction dan krijg je:

Dus het lijkt me dat meerdere depictions bij één property in een box niet met een arraymap functie gaat werken.

Misschien dat je er een aparte functie voor moet schrijven?

[AlexMekkering]

Kijkend naar de definitie van de arraymap functie denk ik dat het iets zoals het volgende moet zijn:{{#arraymap:{{{Person-foaf-depiction|}}}|,|xxx|<img src=xxx>|\n\n}}

Dit plaatst namelijk de aangeboden Template parameter Person-foaf-depiction (welke gedefinieerd is in de infobox) in het src attribuut van een img element en plaatst een newline tussen elke depiction.

[jbachh]

Je hebt gelijk. Ik ga het vanavond implementeren.

[TeunTheunissen]

Joop, de review levert op dat beide oplossingen werken.zowel het dummy arraymap als de semantische koppeling:

[[Person-foaf-depiction::{{{Person-foaf-depiction}}}]]

Bij Tim Berners Lee staat bovenstaande nu in de template.

nb. Het viel me wel op dat de export pagina hoofdletter gevoelig is. 'Tim Berners Lee' en 'tim berners lee' geven verschillende export resultaten.

[jbachh]

Dank Teun voor de review. Nu ook support voor lijst van images. zie http://abiteam30.lukylx.org:3080/mediawiki/index.php/Tim_Berners_Lee die nu ook weer goed gestyled is. @AlexMekkering review r512 aub. ook enkele refactorings.

Zie ook http://is.cs.ou.nl/ABI30/index.php5/Installation_Fresnel_Forms_for_End_Users enkele tips & tricks toegevoegd.

[AlexMekkering]

Styling van de infobox ziet er goed uit, maar ik heb nog de volgende opmerkingen:

• niet voor elke template parameter wordt een lege default waarde gedefinieerd (aan te geven door een pipe (|) zonder inhoud erachter), wat inhoudt dat wanneer deze niet aangeboden wordt, er op die plek in de output {{{variabelenaam}}} komt te staan.
• Wanneer door de gebruiker   wordt aangegeven als scheidingsteken voor lijsten, wordt deze niet als scheidingsteken gezien (er staat geen pipe (|) voor dat scheidingsteken).
• (buiten de scope van dit issue) Volgens mij leveren we nu geen geldige XML op aan MW. Als voorbeeld: volgens mij missen we in de header nog een dubbel quootje en dubbele quootjes in articles zouden volgens mij " of ' moeten worden. Ik wil hier wel even naar kijken en maak hier wel een apart issue voor. Mijn eerste idee is om bijv. Apache Commons library te gebruiken om XML te coderen, dat maakt de code ook weer een stuk leesbaarder.
• Als laatst en meest belangrijke issue: de RDF export van de meerdere depictions gaat nog niet goed. De verschillende depictions staan als één resource in de lijst terwijl er meer aanwezig zijn. Volgens mij komt dit doordat er bij de lijst in de infobox template wel een arraymap wordt gebruikt, terwijl dit bij de dummy property(s) niet het geval is.

Het komt erop neer dat wanneer iets een lijst kan zijn, er dan ook een arraymap voor de dummy div gebruikt moet worden om de properties te exporteren. Wanneer dit niet gebeurt, zal de inhoud van de parameter als één property waarde gezien worden, terwijl het er eigenlijk meer zijn, gescheiden door een scheidingsteken.

Om maar even mijn gedachte hierin vast te leggen zit het volgens mij ongeveer zo, please correct me if I'm wrong:

Er bestaan 2 soorten SMW properties voor FresnelForms:

1. properties met type Page. Voor deze properties hoeft niets bijzonders te gebeuren aangezien deze nu ook al als SMW links naar de bijbehorende Property-page zijn gedefinieerd.
2. properties met een ander type. Waarden voor deze properties zijn in de infobox niet voorzien van een (SMW) link en moeten daarom een extra dummy hidden div gedefinieerd krijgen welke één of meerdere SMW links bevat naar niet bestaande Property pages.

Voor beide soorten properties geldt dat wanneer er een lijst van waarden wordt aangeboden (een string met een bepaald scheidingsteken tussen de verschillende waarden), er dan gebruik gemaakt moet worden van de SF arraymap parser function om de verschillende property waarden van elkaar te scheiden.
De RDF export funcionaliteit van SMW zal elke propertywaarde die het tegenkomt omzetten naar een RDF tripel. Om ervoor te zorgen dat lijstwaarden gescheiden worden behandeld wordt in de MediaWiki parser de samengevoegde propertywaarde middels de #arraymap parser function doorgespeeld aan Semantic Forms welke de propertywaarden van elkaar scheidt.
Na de parse slag zijn de property waarden gescheiden aanwezig en worden aangeboden aan SMW, welke daarna keurig van elke (gescheiden) property waarde een RDF tripel zal maken.

[AlexMekkering]

Correctie op de derde bullet:

• De XML is wel correct, ik was even in de war door de opdeling van Strings waardoor het leek dat de header een niet goed afgesloten attribuut had.
• quootjes in text elementen is wel geldig XML, hoewel het ook met " en ' kan.

De gebruiker kan echter in FresnelForms text invoeren (bijv. iets met een & of een < waardoor het geen geldige XML kan worden. Daarnaast vind ik in de huidige code veel duplicate strings of definities en veel XML encoded strings waardoor het minder goed leesbaar en onderhoudbaar is.

Ik zal hier dus nog een issue voor aanmaken.

[LloydRutledge]

Bedankt, Alex. FF maakt inderdaad verschillende SMW data types. Die van Page is inderdaad belangrijk want die is de default voor object properties in de bron ontologie. En FForm geeft voor elke andere data type voor data type properties in de bron ontology een bepaalde SMW data type, bij default. SMW data types.

Een belangrijk special case is fresnel:value fresnel:image en fresnel:value fresnel:externalLink. Die krijgen (denk ik) allebei URL als SMW data type, en dan andere HTML code in de informbox.

[jbachh]

@AlexMekkering (3 days ago): 1e bulletpoint: Dit speelt toch niet, omdat de div alleen getoond wordt als de parameter bestaat vanwege de {{#if: functie? Voor de zekerheid toch toegevoegd, kan geen kwaad namelijk.

M.b.t. rdf export multi value depictions heb ik nu arraymap voor de dummy div toegevoegd.

Tweede bullet   was al opgelost.

In de commit voor deze issue heb ik ook de checkstyle meldingen in fresnel2wiki en bijbehorende unittests aangepakt. Daarbij zoals je zult zien in het difference scherm van tortoise na de update is de aparte aanpak van extUrls in tplRow() verdwenen. Ik heb de fout die dat zou oplossen met extURLs (dat url waarden niet correct zouden tonen) al langer niet kunnen reproduceren op de test wiki, dus geen nut ( #60 ). Ook wat comments toegevoegd in de code om het duidelijker te maken.

Alex, review ajb (r527). In principe hoef je niet meer functioneel te testen, heb ik al gedaan:

Ik kwam wel een probleem tegen dat de nu niet meer aanwezige wees-props niet meer aanwezig waren in de template informbox Person. Ik zal het ook in #70 melden.

@LloydRutledge fresnel:value fresnel:image en fresnel:value fresnel:externalLink krijgen inderdaad "URL" als data type.

[AlexMekkering]

r527 wilde niet meer bouwen omdat de unit testen ervoor niet slaagden.
Het lijkt erop dat met je commit, een wijziging van mij was teruggedraaid (r525).
Ik heb de delimiter tests gecorrigeerd in r531 en de label tests in r533.

De code ziet er op zich goed uit, maar ik ben het niet eens met je wijziging voor de external URLs. Het klopt dat beide oplossingen (zoals het was, en zoals je voorstelt) er uitzien als links, maar zoals het was geïmplementeerd, was het een hyperlink naar de externe URL (wat volgens mij correct is) en zoals je het voorstelt wordt het een hyperlink naar een (niet-bestaand) artikel binnen de wiki met een naam die gelijk is aan de URL.

Daarnaast zag ik dat de img elementen nog niet XHTML compliant waren (het src attribuut werd niet omvat door quootjes en niet afgesloten). Deze heb ik gecorrigeerd in r532, functioneel is het hetzelfde gebleven. @jheijning, please check.

[jbachh]

Vreemd van die terugdraaiing van de de wijziging, had toch meerdere keren alles opnieuw geïmporteerd en geupdate naar de nieuwste revision vóór het commiten..

Wat betreft die wijziging voor de external URLs: Waarom denk dat je dat het een hyperlink naar een artikel wordt? Zolang de datatype van de property URL is, wordt het gewoon een hyperlink naar de externe URL. Zie http://abiteam30.lukylx.org:3080/mediawiki/index.php/TimTestRDF zowel met de single value als multivalue (arraymap) op de manier zoals ik het nu geïmplementeerd heb wordt het gewoon een hyperlink naar een ext URL, zoals het hoort. Zie ik iets over het hoofd?

[jbachh]

Review ok trouwens.

[AlexMekkering]

Sorry, je hebt helemaal gelijk! Ik had het gedrag van het datatype [[Has type::URL]] helemaal over het hoofd gezien. Ik had zelf even een test gedaan maar niet die property gezet 😊.

Dus... review OK! case closed!