Definitie van het datatype van een property met fresnel of owf. #42
Comments
TeunTheunissen
changed the title
|
Is dit misschien iets voor de fresnel:value? Als je kijkt naar de GUI zie je rechtermuisknop op property, changeType, dan kun je kiezen uit URI, Image en externalLink. Zie ook de FRESNEL vocabulary klasse. Alex had al Image en external link als waarde hiervoor ingevuld. Dus als in de gui iemand Image als type selecteerd, kan ik dat met fresnel.value opvragen. Zou waarschijnlijk handig zijn als standaard (dus iemand kiest niet voor type image of external link) de XSD.*** waarde hier komt. *** is dan integer, date, etc. of RDFS.Literal. |
|
ps. zie ook fresnel2wiki.loadHashmap(). |
|
Ik stel voor dat fresnel:value een subproperty wordt van owf:datatype. Dus is elke fresnel:value ook een owf:datatype. En de drie mogelijke waarden van fresnel:value hetzelfde betekenen voor owf:datatype als voor fresnel:value. Maar dan heeft owf:datatype dan ook veel meer mogelijke waarden. Zoals alles op owf: wil ik een duidelijk verband met SMW en Forms. Voor de box heeft owf:datatype een duidelijke verband op SMW datatypes zoals op https://semantic-mediawiki.org/wiki/Help:List_of_datatypes . Die bepalen hoe de waardes voor elke property tonen om wikipagina’s met die waarden. Dus zou Joop’s fresnel2wiki de owf:datatype waarden om de [[Datatype::]] te zetten op de Property: pagina voor die property. En dan voor de form is de “input type=” paramater in de ‘field’ tag in Semantic Forms van toepassing (zie http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms#.27field.27_tag). Het is niet nodig om deze expres te specifiëren als de Property: [Datatype::]] van toepassing is van in Forms is dat de default. Maar Forms heeft een superset voor mogelijkheden hier achter de (default) datatypes. Die en hun relatie met hun default datatypes zie je op http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms#Allowed_input_types_for_data_types. Ik wil graag deze soort aanpak volgen in het algemeen voor het gebruiken van SMW en Forms voor de OWF uitbreiding op Fresnel Het wordt ingewikkeld als één property op verschillende boxes toont met verschillende owf:datatypes. Een oplossing hier is om een elke aparte Property: pagina op de wiki te zien niet als de property zelf maar als een format voor het weergave van die property. Zo nodig zou elke format property pagina een SMW subproperty zijn van de pagina voor de property zelf. Deze regels dat SMW query’s op die property alle format-bases subproperties ook zien. Hopelijk hebben jullie hier een formule voor het maken van de OWF uitbreiding owf:datatypes over fresnel:value voor de OWF ontologie. En voor de conversie van deze naar wiki code. En dat het klopt … maar ik vermoedt terugkoppeling van jullie over waar het wat ingewikkelder wordt ;) . En dat het uitvoerbaar is. |
|
Ik begrijp dat het eerste prioriteit heeft om de Property: pagina de juiste [[Has type::]] tag te geven, en dan later te kijken naar de superset en subproperties? In ieder geval is er al een methode frmsParams() in fresnel2wiki die het formulier een radiobutton geeft indien het [[Has type::]] boolean is. Deze wordt nu nog niet gebruikt, omdat de datatypen nog niet in de fresnel worden gegenereerd. |
|
Property: met [[Has type::]] is prioriteit omdat die de default input type voor de Form: bepaald. Dan hoeft je alleen expliciet Forms input type parameters te regelen voor een default override. Allebei worden bepaald door fresnel:values en zijn superproperty owf:datatype. Mijn voorstel over SWM subproperties heeft inderdaad laag prioriteit. Die enige nut is dat SMW inline query's goed werken. Maar op lange termijn wil ik voorstellen dat de SMW query's eigenlijk op de RDF via een SPARQL endpoint met reasoning uitvoert. Dus hebben SWM subproperties zowel laag prioriteit als korte termijn belang. Aan de andere kant: die zijn makkelijke te implementeren. Drie makkelijke stappen:
Nu heb je meerdere format Property: pagina's per property als die property op meerdere boxes toont. Dat is nu al in ieder geval zo. We kunnen rekening houden met het verschil door nog een laag van namespaces in de pagina toe te voegen. Dus de box naam voor de property naam. Bijvoorbeeld Property:Person:Name. Als we de superproperties uitvoeren dan moeten we de value format en de "abstract" property apart van elkaar houden te houden. Hier kunnen we nog een paginanaamprefix toevoegen. Property:Format en Property:Abstract misschien? En dan hebben we misschien nog een laag namespaceprefix voor de ontologie, Dus als je een "name" property van zowel skos: als foaf: hebt dan heb je deze pagina's nodig: Property:Format:Concept:Skos:Name "Concept" en "Person" zijn de namen van de forms/boxes die de property type gebruiken. Klopt dit helemaal? We kunnen nu kiezen om de Format/Abstract laag voorlopig uit te houden en dus nog geen superproperties implementeren. Maar de andere namespace lagen zijn volgens mij nodig. |
|
Teun, kan je regelen dat fresnel:value gebruikt wordt in het OWF-Frenselbestand als de 3 fresnel:value waarden gebruikt worden? En dan natuurlijk alleen voor de andere waarden dan owf:datatype gebruiken? |
|
We hebben naast owf:datatype ook owf:inputtype nodig als er input types zijn die verschillende data types hebben. |
|
Lloyd, ik heb het datatype gedefinieerd in de fresnel_owf ontology, ben je het eens met de opzet? |
|
Hallo Teun, over je vraag: de mapping voor fresnel2wiki bestaat al zo ver ik weet, die was oorspronkelijk gemaakt door Lloyd in OWF.php en nu vertaald naar loadRangeMap() in fresnel2wiki java. Het zijn +- 40 XSD (en RDFS/Fresnel) types naar 5 SMW types. |
|
Ik het net https://svnext.ou.nl/INF_Studenten_ABI_team30/source/trunk/FresnelForms/design/OWFdev.xlsx op SVN gezet. Die is een tabel van features in OWL, Fresnel en SMW en de relaties tussen. Die "relaties" zijn eigen hoe dingen geïmplementeerd worden: OWL->Fresnel is de automatisch initiële Fresnel, en hoe die aangepast kan worden. Fresnel->SMW zijn features or feature requests for fresnel2wiki. Ik schrijf dit hier omdat die tabel heeft o.a. de mapping van XSD datatypes naar (soms) Fresnel en naar SMW. Kunnen jullie deze tabel bekijken om en zeggen of de tabel consequent is met wat jullie geïmplementeerd hebben? Zijn er fouten te corrigeren? Of voorstellen voor verhelding, uitbreiding of verbetering van de tabel? Hoor ik het graag! Of jullie kunnen de tabel zelf aanpassen. Ik maak nu een apart issue over de tabel, met erbij het verzoek om de boven activitieten over types in het algemeen toe te passen zodat we een correct en behulpzame tabel krijgen. |
|
Teun, over de onto: Je algemeen opzet voor namespace lijkt me goed. Hierbij enkele comments. Kan je ons URI http://is.cs.ou.nl/OWF/OWF_style# maken? Fresnel hoeft niet in de namespace te zijn. Onto's lenen van elkaar heel vaak, natuurlijk. Dat zie je in de onto RDF; hoeft niet in de namespace dus. Je maakt zelf URIs voor de datatype waardes. Maar XSD heeft al URI's ervoor.Die worden door RDFS en OWF en Protégé gebruikt. Dus pas ajb de onto aanpassen zodat ons verwijzing naar de datatypes ermee consequent is. De namespace voor datatypes is http://www.w3.org/2001/XMLSchema . Officieel spec is http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#namespaces . Voorbeeld gebruik is op http://www.w3.org/TR/rif-dtb/ . Hebben deze XSD datatypes dan een class met een URI? Dan kan je die gebruiken in je range met een UNION op de drie Fresnel. Of de URI van de Fresnel class voor de drie? Gebruik dus class URI's ervoor als die al elders opgesteld zijn want dat is meer efficiënt en voor velen duidelijker. |
|
Na een vluchtige scan lijkt mij dat de OWFdev.xslx definities van de xsd waardes overeen met wat er in PHP en in de plugin geprogrammeerd staat. |
|
Teun, mijn excuses. Ik realizeer me nu dat je SWM datatypes gebruikt hebt in de ontologie, niet XSD datatypes. Dus ja, ga XSD gebruiken waat het kan. En dat met hun URI's. Wil je dan misschien ook een aparte owf: class opstellen voor SMW datatypes. Met een SMW namespace en prefix, dat je waarschijnlijk zelf moet verzinnen als het niet te vinden is? En dat al ID fragment gewoon de waarden op SMW voor de datatypes? Dus zal je wat "dubbel" hebben tussen XSD en SMW datatypes. Niet erg. Laten we die dubbel in de onto hebben en dubbel implementeren. Maar dan een voorkeur hebben voor het opslaan met de XSD. Joop, kan je er rekening me houden in Fresnel2wiki, met how de frensel:, xsd: en owf/smw: waardes naar SMW Property: met [[Datatype::]] en Forms input type= geconverteerd wordt? Ik heb OWFdev.xlsx aangepast met de XSD en SMW datatypes. Klopt de tabel nu wat beter? Alex, als dit allemaal stabiel is kan je die in de GUI implementeren? Waar er XSD/SMW dubbel is geef dus alleen de XSD als optie. |
|
Dat had ik begrepen, ik zal de xsd types gebruiken waar het kan. De SWF datatypes wou ik in onze owf_style ontology definieren. Jouw voorstel om een SMW namespace te verzinnen kan ook natuurlijk maar ik vroeg me af of je zomaar een fake namespace en identifiers mag opstellen ? |
|
Je hebt wel gelijk. Gebruik dan gewoon de SMW [[Datatype::]] waarde strings binnen de owf: namespace. Kan je dat noteren in de rdfs:comment voor de class en elke datatype individual? |
|
Ik heb de ontologie aangepast met 'named' SWF datatypes (zie revisie 304). De comments maken duidelijk dat het om SWF datattypes gaat. De property owf:datatype kan nu als volgt gebruikt worden :freeLancesToFormat rdf:type fresnel:Format ; voor owf:URL. kan ook owf:Page, owf:Number, owf:Date, owf:Boolean ingevuld worden. @LloydRutledge Ben je het met de constructies in deze ontology eens? |
|
Ik stel voor dat je fresnel:PropertyValueStyle and owf:WikiFormsDataType als aparte classes houden, zonder sub of super. Of breekt dat iets? En dat je een class vind (of maakt) voor XSD datatypes. Dan stel ik voor dat je de range van :datatype opstel als de UNION van drie classes maakt. Is dat goed? |
|
De aparte classes en de union kan heel goed, ik heb een testversie gemaakt. Begrijp ik het verder goed, dat je naast de :WikiFormsDataType classe, waarin de SMW Forms datatypes gedefinieerd zijn, een classe wilt voor XSD types? |
|
Je kan een blank node class maken in de union voor alle vier groepen: fresnel values, XSD datatypes, SMW datatypes en Forms input types. Je hoeft geen nieuwe URI voor elke set waarde-URI's te verzinnen. Natuurlijk als een dergelijke URI al bestaat dan is het best om die te gebruiken. Anders kan je gewoon een blank node per "class" in de union zitten met de URI-waardes erin. Wel een aparte blank node per groep. Met een verhelderende rdfs:comment per blank node a.u.b. En de range wordt dan inderdaad de union van die vier. Volgens mijn is het noch nodig noch zinvol om in de ontologie zelf een verband tussen XSD en SMW types te liggen. Zeker geen owl:sameAs. En geen subClassOf of subPropertyOf want dit betreft individuals. Wel moet er een verband zijn in ons implementatie zoals in de ontology2fresnel maan dan kan dat alleen in de Java-code. |
|
Nuttig bron van XSD datatypes, hun URI's, en zelf hun hiërarchie in de introductie subsection van http://www.w3.org/TR/xmlschema-2/#built-in-datatypes . Je zou van de hiërarchie en equivalent subClassOf hiërarchie maken maar dan is dat alleen zinvolle als je iets specifiek met een hele subclass doet. |
|
OK, ik begrijp het maar wat ik niet begrijp is waarom wil je in de owf_style ontology voor de property 'datatype' een xsd datatype kunnen definieren? Want de datatype waarde wordt toch alleen gebruikt om een SMW Form definitie te genereren? In een SMW Form tag kun je toch geen xsd type opnemen? |
|
Goede vraag. Een good practice in het bijzonder op het SW is hergebruik van URI's. De XSD datatype URI's betekenen een duidelijke iets voor iedereen. Nog een good practice is om onze ontologie zo breed mogelijke inzetbaar te hebben. We implementeren die op SMW. Maar andere mensen zouden andere systemen ervoor maken en gebruiken. Dus de OWF-Fresnel bestanden van onze plugin zouden ook in niet-SMW systemen gebruikt kunnen worden. Ik wil wél SMW namen gebruiken voor begrippen die we van SMW lenen. Maar dan alleen als er geen algemener bron is voor dezelfde begrip. XSD is natuurlijk algemener dan SMW. Daarom wilde ik ooit ook XForms gebruiken als ID/URI/begripbron. XForms zou minder algemeen dan XSD maar algemener dan SMW zijn. Maar voor XForms hebben we te weinig tijd met te weinig zekerheid dat het iets interessants of nuttigs oplevert. Dus hier is een ranglijst van algemene URI/ID/begrip-bronnen: XML > XSD > (XForms >) MW > SMW > Forms. Je vraagt "waarom wil je in de owf_style ontology voor de property 'datatype' een xsd datatype kunnen definieren?" maar volgens mij stel ik de tegenovergestelde voor. We definieren XSD datatypes juist niet in de OWF onto want de URI's zijn al gedefinieerd in de XSD spec. We gebruiken dus de al gedefieneerde XSD URI's in ons onto. Het SW is het gebruik van shared vocabularies, en XSD is een shared vocabulary, dus laten we die gebruiken. En ja, dat we het als XSD definiëren eist en vertaalslagje naar SMW in fresnel2wiki maar Joop programmeert dat makkelijk een keer en dan draait die probleemloos bij elke conversie. Bijvoorbeeld as en OWF styliste weet dat een property waard altijd een integer is en wilt zeggen dat de inferface (wiki of iets anders) die presenteert als een gewoon integer (hoe dat systeem dat dan ook doet) dan wet ie dat xsd:integer dat datatype beschrijf in een manier waarmee velen nu al goed begrijpen en weten dat andere die ook hetzelfde begrip voor hebben. Ja, er is lang niet altijd een 1-1 matching tussen XSD en SMW. Er is bijvoorbeeld veel XSD die gewoon [[Datatype:number]] wordt bijvoorbeeld. Maar volgens mijn is de mapping duidelijik en makkelijk te implementeren. Ja, de GUI heeft van veel keuzes voor wat gewoon "number" wordt op veel interfaces. De GUI voor het kiezen van een datatype kan wat gemakkelijker worden door een hiërarchie ervoor de hebben. Misschien eerste fresnel:value vs XSD vs datatype vs inputtype en dan de XSD hiërarchie op http://www.w3.org/TR/xmlschema-2/#built-in-datatypes ? Of misschien de XSD hiërarchie als begin punt als boven deel van de totaal hiërarchie, met compomenten van de andere bij verschillende plekken eronder? En ook bijvoorbeeld dat [[Datatype::Number]] een tak wordt voor de XSD numbers. Wordt een lange hiërarchie maar straightforward te programmeren (denk ik), en met de juist folding optie makkelijke genoeg voor de gebruiker. Ja, lijkt raar om in de GUI en OWF-Fresnel xsd:unsignedLong op te stellen voor iets dat gewoon [[Datatype::Number]] wordt (zoals veel XSD). Maar misschien komt er ooit een system dat een bepaalde interface heeft voor xsd:unsignedLong. Hopelijk heeft dit respons iets met je vraag te maken ;) |
|
Hallo Loyd, jouw response heeft absoluut iets met mijn vraag te maken :-). :DatatypeValue a owl:Class; Het idee is dat voor de range van het owf:datatype predicaat een simple xsd type zoals xsd:Integer gebruikt kan worden of een van de 3 types die gedefinieerd zijn in fresnel:PropertyValueStyle Voorbeelden: Komt dit beter overeen met jou idee voor algemeen toepasbaar zijn van het predicaat? |
|
Algemene ondersteuning voor owf:datatype toegevoegd in r334. Het datatype van datatypeProperties sijpelt nu door vanuit de bronontologie naar default formats voor de properties in de fresnel output en kunnen via helper methode getFormattingProperties opgevraagd worden. |
|
Zoals beschreven bij #29 is de ondersteuning voor meermalig gedefinieerde properties geimplementeerd in r337. @jheijning, wil jij r334 reviewen? Let daarbij alsjeblieft met een schuin oog op delen van r337 aangezien ik niet kon voorkomen dat er enig overlap plaatsvond. |
|
@AlexMekkering : Ik zie dat je in thefirm.fresnel indirectlyContractsToFormat owf:datatype fresnel:image hebt gegeven. Dit zou dus gekomen zijn uit de bronontologie en niet aangegeven door de gebruiker in de GUI met "Change type". Ik ga er dus van uit deze hypothetische gebruiker deze property value niet als image wil laten zien. attribuut isImage in fresnel2wiki blijft dus false. Alleen true indien gebruiker dat aangeeft in de GUI dus. Verder alles goed! Review je nog even de implementatie r339 ajb? ps. jammer dat dbpedia_2014_TBL_extract.owl de properties waar je een string verwacht (title en birthname) krijgen nog gewoon type "page" , omdat de range niet is gedefiniëerd. birthDate krijgt wel type "Date" gelukkig. |
|
owf:datatype fresnel:image in thefirm.fresnel indirectlyContractsToFormat is door jezelf toegevoegd in r331 (kun je mooi zien met het TortoiseSVN commando met de sprekende naam 'Blame' 😉). Review zal ik later oppakken... |
|
@TeunTheunissen, Alex schreef: "jammer dat dbpedia_2014_TBL_extract.owl de properties waar je een string verwacht (title en birthname) krijgen nog gewoon type "page" , omdat de range niet is gedefiniëerd. birthDate krijgt wel type "Date" gelukkig." Die properties zijn in https://svnext.ou.nl/INF_Studenten_ABI_team30/Environment%20&%20Misc/Ontologies/DBPedia_TBL_Extract/dbpedia_2014_TBL_extract.owl aangegeven als "rdf:type owl:DatatypeProperty". En dan zonder range. Kan DatatypeProperty zonder range toch in de default Fresnel genorator toch en string (of zoiets) datatype krijgen in de Fresnel-OWF output? |
|
Lijkt me een goed plan! Al is het alleen maar om onderscheid te kunnen maken tussen DataType Properties en Object Properties in de Fresnel-OWF output. @TeunTheunissen, kun jij deze kleine wijziging reviewen? |
|
Vwb de conversie naar SMW valt me op dat de Property Pages geen geldige verwijzing hebben naar een Form.
Volgens mij moet de fout ergens gezocht worden in de implementatie van methode rngName. |
|
Bedankt, Alex. De Form dat een property krijgt wordt bepaald door de range van de property. Op lange termijn moeten we die misschien beperking tot ranges naar alleen één class met een bepaalde vorm. Moeten we dan ook geen default form zetten voor properties zonder range naar één class? Komt nu altijd een default form bij elke property maar dan soms leeg? Datatype properties moeten zeker geen default form krijgen. |
|
@AlexMekkering Ik was inderdaad te snel met committen, ik was nog bezig met een grote fresnel2wiki refactoring. Nu is de bug gefixed. Ook een test toegevoegd voor frmsParams(), voor het geval de data type property range boolean heeft. Zou je willen review aub? Wat betreft de refactoring: Ik ga er nu van uit dat een property een Object property is XOR een data type property, dmv het attribuut objectPropRngName. Dat blijft null bij een data type property. Onder meer daardoor heb ik fresnel2wiki behoorlijk versimpeld. Ik ben nog een probleem tegengekomen met betrekking to range van object properties: De range van Object properties gaat via owf:autocompleteFromClass. Maar deze wordt alleen meegenomen indien een gebruiker autocomplete aanzet in de gui. fresnel2wiki moet de range van een objectproperty ook weten als de autocomplete uit staat, namelijk voor die regel This property uses the form Form: (en misschien wel andere dingen in de toekomst). Wat denk je hiervan? ps. de refactoring hoef je wat mij betreft niet helemaal na te gaan in de review, zie maar. |
|
Aangezien elk Datatype Property nu altijd een owf:datatype heeft (Een DataType Property zonder range krijgt default owf:datatype xsd:string) kun je volgens mij je beslissing of iets een ObjectProperty is of een DataType Property beter later afhangen van of iets een owf:datatype heeft. Review volgt later... |
|
Als je dan weet of iets een ObjectProperty is, heb je nog steeds niet zijn range, als de gebruiker autocomplete niet aan heeft gezet.. |
|
@LloydRutledge Nu krijgen alleen ObjectProperties een default form, indien de range bekend is. het probleem (mijns inziens) is nu nog dat fresnel op dit moment nog niet standaard doorgeeft wat de range van een objectproperty is, maar we zijn er mee bezig. |
|
Wanneer we voor alle properties (DataType & Object) de range nodig hebben, zouden we mijns inziens net zo goed bijv. een owf:range kunnen opvoeren ipv owf:datatype en owf:autoCompleteFromClass de range xsd:boolean geven (en gewoon owf:autocompletion noemen welke by default false zou zijn). |
|
Dat lijkt me ook. |
|
Waarom moet er (altijd?) een owf:range zijn? Is het niet eenvoudiger om datatype string in de default Fresnel voor Datatype properties zonder ranges op te stellen? De gebruiker kan die dan veranderen als hij dat wilt. |
|
Het gaat om Object properties. In Fresnel hebben die op het moment nog geen range tenzij een gebruiker autocomplete inschakelt in de gui (dan komt er een owf:autocompleteFromClass: range). ps. datatype props krijgen nu inderdaad default String. |
|
@AlexMekkering Trouwens, als je owf:range zou opvoeren, hoe kun je dan onderscheiden tussen datatype en object properties? Is van belang voor het bijvoorbeeld opgeven van een form This property uses the form Form: Deze regel is natuurlijk niet van toepassing voor datatype props. andere optie is owf:datatype en owf:objecttype ? en als een object property geen range heeft meegekregen, krijgt hij standaard range "thing"? standaard range Thing geven was trouwens de oplossing in OWF.php. In fresnel2wiki op dit moment is dat niet zo, omdat er van uitgegaan wordt dat er een owf:autocompleteFromClass wordt meegegeven aan object properties pspsp andere oplossing is dat zodra er geen owf:datatype string of anderzins aanwezig is, dan moet het wel een object prop zijn, want datatype props krijgen default string indien er geen range is. Maar dan blijft het probleem dat je een object property niet standaard Thing als range wil meegeven als er geen owf:autocompleteFromClass bestaat, tenzij die objecct prop oook echt geen range heeft. |
|
Samenvatting: het zou het mooiste zijn, mijns inziens, als er naast owf:datatype ook een owf:objecttype komt voor objectproperties, die -indien er geen range bekend is- standaard "Thing" heeft (net zoals owf:datatype standaard "string" heeft). Snijdt dit hout @LloydRutledge ? |
|
Goede punten! owf:autoCompleteFromClass zou dan dus owf:objecttype moeten worden t.b.v. de identificatie van ofwel datatype- ofwel objecttype properties en owf:autocompletion zou een xsd:boolean moeten worden om aan te geven dat gebruik gemaakt moet worden van de range(s) van owf:objecttype voor autocompletion (standaard false). |
|
Van mij klopt owf:autoCompleteFromClass beter dan owf:objecttype. Fresnel-owf beschrijf alleen de interface; die hoeft niet de ontologie te herhallen want die bestaat al. En de class hier zou Semantic Forms alleen voor autocompletion gebruiken. Of een andere soort expliciet hulpmiddel zoals pulldown, die dan nog een owf: optie zal krijgen. Met owf:autoCompleteFromClass wil ik zeggen dat de autocompletion gaat gebeuren. Zonder autocompletion of andere help bij een object property hoef je niks te zeggen. Zonder object range in Semantic Forms krijg je gewoon een veld waarin je een paginanaam intypt. Hoeft niet eens al te bestaan - dan toont het als rood. By default op Semantic Forms komt er zoiets als een [[datatype::page]] bij object property waarde-velden. owf:objecttype geeft hier geen nuttig informatie. Het lijkt me voorlopig best als geen object range (en ook geen equivalent via allValuesFrom) via default generation gewoon een paginanaam veld zonder autocompletion wordt. Wel [[datatype::page]] bij de property pagina. Op langere termijn kunnen we de volle class-hierarchie ook een volle MediaWiki [[Category:]] subcategory hierarchie maken met [[Category:owl:Thing]] als de top. Dan vallen alle pagina's via SMW inheritence automatisch onder [[Category:owl:Thing]] als ze maar een direct class en [[Category:]] hebben. En dan kan je bij default op object properties zonder range en zonder someValuesFrom een [ owf:autoCompleteFromClass owl:Thing]] zetten die dan in de Semantic Forms parameters |autoCompleteOnCategory=owl:Thing (of zoiets) wordt. |
|
OK, dan werkt fresnel2wiki op dit moment volgens alle requirements zoals Lloyd hierboven meldt. De property pagina zal dan alleen This property uses the form Form: hebben in het geval van autocompletion, en niet getoond worden in het geval van niet. |
|
Review OK! |
No description provided.
The text was updated successfully, but these errors were encountered: