188 URI van model en modelelementen voor publicatie op het web

[Bakkej]

(hoofstukken van de werkversie, niet gepubliceerde versie)	hfds	Titel	doen	beschrijving	Afhandeling
H2.4.2	modelelementidentificatie-metagegevens	misschien	Kan dit niet beter onder 2.4.3?
H3.2	specificatie-metagegevens-in-uml		opnemen metagegevens in specificaties	Gedaan
H4.2.1	kern-1		Update diagram(men)
H4.3	specificatie-metagegevens-in-ld		opnemen metagegevens in specificaties	Gedaan
H5.13	externe-schema-s-her-gebruiken		Update aanvulling hergebruik van Attribuutsoorten/relatiesoorten en URI's
H5.16	afspraken-rondom-naamgeving-en-definities		iets over URN van modelelementen?	Hier is iets toegevoegd; vereist wellicht meer introductie
H6.1.2	modelelementen-en-metagegevens-als-diagram		Update diagrammen
H6.4	transformatie-mim-rdfs-owl-shacl		maar gebruik van metagegevens voor transformatie	gedaan
H6.3	vertaling-naar-engels		Voeg metagegevens toe	geen mapping naar iso:19109 gevonden
BP4MC2			Update rdf vocabulaire
BegrippenXL			Update skos

Open vragen:

• In alle specificaties staat URI toegelicht als algemeen metagegeven - checken of dit de juiste toelichting is.
• URI is optioneel bij een modelelement; eigenlijk niet correct. Het missen van een URI zou minimaal een warning kunnen geven. Basis-URI is daarnaast verplicht. Echter is dit alleen maar een manier om snel te zorgen dat alle modelelementen een URI krijgen, in essentie is de basisURI niet erg belangrijk (de URI juist wel).
• Is isGedefinieerdIn verplicht of optioneel? hint: Herkomst is wel verplicht.
• In MIM-LD heeft isGedefinieerdIn als range owl:Ontology. Is dit handig of liever mim:Package, of mim:Informatiemodel (EN/)OF mim:Domein
• in ### Tansformatie Attribuutsoort wordt aangegeven dat een attribuutsoort in mim geen first class citizen is; klopt dit wel nu mim:Attribuutsoort een object is?
• aan de LD kant wordt de domeinpackage als 'het eigen informatiemodel' gezien. aan de UML kan heb ik het idee dat juist het informatiemodel package als het eigen IM gezien wordt. Hierdoor lopen de teksten niet altijd gelijk. https://docs.geostandaarden.nl/mim/mim/#transformatie-domein

Nog aparte issue aanmaken voor:

• Volgens mij klopt tabel 6.4.4.1 Klassen voor ReferentieElement niet. Een referentielijst beschrijft de structuur van de referentiewaarden, het is een owl:Class en een sh:Nodeshape. Een Referentieelement beschrijft één (van de) eigenschappen die Referentiewaarden kunnen hebben, zoals een "code". Referentieelementen moeten we daarom vertalen naar een propertyshape en een datatypepropery bij de nodeshape van de referentielijst en niet naar een owl:Class en een sh:NodeShape.
• bevatModelelement is niet beschreven in metamodel algemeen.
• http://127.0.0.1:5500/index.html#mim-gegevensgroeptype heeft geen HERKOMST aantal andere tabellen komen in het hoofdstuk over Metadmodel in Linked Data ook niet overeen met het UML metamodel.
• ordening van rijen in de tabellen verschillen in Metamodel in LD onderling en vergeleken met Metamodel in UML
• In 4.2 geven we aan dat een Klasse wordt beschreven met sh:name; dit is niet correct omdat dat betekent dat een owl:Class een sh:PropertyShape wordt (op basis van de rdfs:domain van sh:node). Ook hier kan alleen rdfs:label gebruikt worden.

  Elk voorkomen van een MIM «metaclass» kent ook een sh:NodeShape met een sh:name die overeen komt de originele technische naam (UpperCamelCase);

• definitie en gebruik van mim:locatie recht trekken. Wellicht ergens toevoegen: Bij een waardelijst duidt mim:locatie een distributies van de waardelijst aan. Waardelijsten hebben een rdfs:isDefinedBy omdat dit klassen zijn. mim:locatie verwijst naar een distributie waar waardelijst te downloaden valt. Enumeratiewaardes zijn named individuals en die worden ook binnen de ontologie gedefinieerd. 2.4.3.22 Metagegeven: Locatie wordt nu op meer plekken gebruikt dat conform de definitie is toegestaan. Bijvoorbeeld bij Extern en Views https://docs.geostandaarden.nl/mim/mim/#specificatie-metagegevens-voor-packages

[architolk]

Per punt even opmerkingen, dan kan daar ook weer op gereageerd worden:

Over H2.4.2: ik zou die wel afzonderlijk houden, want identificatie is een belangrijk ding, dus die metagegevens zijn goed om afzonderlijk te beschrijven.

Wel moeten we aandacht gaan gegeven aan wat nu precies "identificatie" is. Want nu is URI gedefinieerd als de identificatie van een modelelement. Dus als twee modelelementenbeschrijvingen dezelfde URI hebben, dan gaan deze beschrijvingen over hetzelfde modelelement. Dat zou dus betekenen dat twee attribuutsoorten die in twee objecttypen worden gebruikt, maar dezelfde URI hebben, feitelijk hetzelfde attribuutsoort zijn (!). Dus moeten we dan geen onderscheid gaan maken? Dus tussen attribuutsoort en attribuut? Enkele eigenschappen van een attribuutsoort kunnen namelijk verschil per objecttype, maar als de URI van die twee dezelfde is, dan gaat het weer wel om hetzelfde modelelement (!?!)

[architolk]

Over URI als optioneel veld: eigenlijk is dit verschil tussen expliciet opnemen of afleiden... Een URI is altijd aanwezig, maar kan afgeleid worden indien deze niet wordt opgenomen. De vraag is dus wat "verplicht" betekent... Ik zou zeggen dat je altijd een URI moet kunnen afleiden, maar dat deze niet expliciet opgenomen hoeft te worden. Wellicht zou een betere oplossing kunnen zijn om er een verplicht veld van te maken, met een default waarde?

[architolk]

als ik het goed begrijp betekent isGedefinieerdIn dat het aangeeft in welke package je de basis-URI moet zoeken voor het betreffende modelelement. Dat zou dus bij views wel verplicht moeten zijn, maar bij andere packages hooguit optioneel. Ook hier speelt dat je isGedefinieerdIn wel altijd kunt afleiden. Die afleiding is denk ik nog wel twijfelachtig: want dat zou niet per sé de directbovenliggende package hoeven te zijn, maar (denk ik?) de package waarin de basis-URI juist staat...

[architolk]

Ik denk idd dat we in MIM-LD de range van mim:isGedefinieerdIn moeten aanpassen. Deze was oorspronkelijk denk ik geïnspireerd op rdfs:isDefinedBy, vandaar de betreffende range. Maar nu is meer duidelijkheid over packages, en kunnen we hem daaraan koppelen. Lijkt me idd OF mim:Informatiemodel OF mim:Domein.

[architolk]

Over mim:Attribuutsoort als first-class citizen: ik denk dat we dat moeten heroverwegen. Dat klopt denk ik niet meer helemaal (door de definitie van URI in het algemene metamodel (!)). Elk "ding" dat in MIM nu een URI kan krijgen, kan per definitie first-class worden. Maar mim:Attribuutsoort is nu ingewikkeld geworden, zie ook vorige punt: want bepaalde zaken horen echt wel bij het objecttype (en dus eigenlijk bij de rol "attribuut" van de relatie, en dus niet bij mim:Attribuutsoort zelf (!). Of we moeten de URI weghalen bij mim:Attribuutsoort (liever niet...)

[architolk]

bij mim:View speelt overigens iets soortgelijks: een mim:View gaat over een mim:Objecttype in een ander model, maar wat er vervolgens in de mim:View staat heeft waarde op zichzelf. Een mim:View lijkt op een sh:NodeShape, waarbij dan de sh:targetClass verwijst naar het oorpronkelijke mim:Objecttype. Maar dan heeft mim:View dus eigenlijk twee URI's nodig: hoe doe je dat???

[architolk]

Domein vs Informatiemodel: die moeten we ook nog goed aflopen. Nu is het nl zo dat "Informatiemodel" in UML het topmodel is, maar vaak zit onder dat topmodel bv iets als IMBAG en NEN3610 en..., dus dan heb je meerdere packages onder de "root" package. Hier wil je vrijheid in hebben als modelleur, maar het moet wel duidelijk zijn wat je nu waarvoor moet gebruiken.

[architolk]

Over 6.4.4.1: klopt, die mapping in de tabel is onjuist.

[architolk]

bevatModelElement zou idd ook in het metamodel moeten zitten. Ik meende dat ik hiervoor al eens een issue voor heb aangemaakt. Punt is dat je dit "cadeau" krijgt in UML (de packagestructuur), maar feitelijk moet het dan natuurlijk ook in de abstracte taal beschreven zijn. Een bijkomend puntje is volgorde: het huidige metamodel kent geen volgorde, en dus kun je in LD ook geen volgorde specificeren. Met als gevolg dat in de gegenereerde plaatjes de volgorde willekeurig is. Terwijl je in UML juist ALLEEN maar een volgorde kunt aanbrengen. Volgens Lennart heeft die volgorde geen betekenis, maar toch zullen modelleurs in de ReSpec uiteindelijk dezelfde volgorde willen terugzien als zij in het model hebben opgenomen. Dat kan nu niet. Een (mooie) oplossing zou zijn om ook een stukje diagram-specificatie toe te voegen aan MIM, zodat je bv ook positionering van elementen enzo kunt toevoegen.

[architolk]

M.b.t. metamodel: goed plan om de cardinaliteiten enzo tussen de abstracte syntax, UML en LD weer opnieuw te controleren. Ooit wel gedaan, maar dat is in de loop van de tijd nog wel eens verandert. Idealiter gebruiken we de nieuwe UML versie om vanuit daar de LD versie te genereren, dan kunnen we ook gelijk zien of alles op zijn juiste plek beland...

[architolk]

Over sh:name: voor mijn gevoel is het een fout geweest van de SHACL specificatie om sh:name (en sh:description) te beperken tot de sh:PropertyShape. Waarom dit niet op sh:Node niveau opnemen? Maar je hebt wel gelijk. Zoals het er nu staat, klopt het niet. Het zit ook het ingewikkelde punt rondom mim:naam en mim:alias, dat blijft voor mijn gevoel een ingewikkeld en overbodig moeilijke oplossing. We hebben dan echter wel een alternatief nodig...

Wellicht is het een idee om te stellen dat we de rdfs:label gebruiken bij sh:NodeShape ne sh:PropertyShape om te verwijzen naar de technische naam, en rdfs:label bij owl:Class en owl:DatatypeProperty/owl:ObjectProperty voor de mens-leesbare naam?

[architolk]

mim:locatie moeten we idd herzien (als dat nog niet gedaan was), want oorspronkelijk was mim:locatie de manier om URI's te munten, maar nu gaat dit via basis-URI.

[pmaria]

@architolk schreef:

Over URI als optioneel veld: eigenlijk is dit verschil tussen expliciet opnemen of afleiden... Een URI is altijd aanwezig, maar kan afgeleid worden indien deze niet wordt opgenomen. De vraag is dus wat "verplicht" betekent... Ik zou zeggen dat je altijd een URI moet kunnen afleiden, maar dat deze niet expliciet opgenomen hoeft te worden. Wellicht zou een betere oplossing kunnen zijn om er een verplicht veld van te maken, met een default waarde?

We kunnen in het algemeen geen verplichte metagegevens toevoegen tenzij er altijd een default waarde is. Anders is het een breaking change. Als we dit verplicht maken dan moet de afleidingsregel ook geimplementeerd worden in alle mim-model verwerkende software. Ik zou het voor nu, om die reden, optioneel willen laten.

Dat geldt overigens ook voor de andere metagegevens.

[pmaria]

@Bakkej schreef: In MIM-LD heeft isGedefinieerdIn als range owl:Ontology. Is dit handig of liever mim:Package, of mim:Informatiemodel (EN/)OF mim:Domein

@architolk schreef: Ik denk idd dat we in MIM-LD de range van mim:isGedefinieerdIn moeten aanpassen. Deze was oorspronkelijk denk ik geïnspireerd op rdfs:isDefinedBy, vandaar de betreffende range. Maar nu is meer duidelijkheid over packages, en kunnen we hem daaraan koppelen. Lijkt me idd OF mim:Informatiemodel OF mim:Domein.

Wat doe je als je voor een modelement een URI gebruikt van een bestaande standaard? Moet je dan isGedefinieerdIn invullen? Zo ja, wat is dan de waarde, als dit geen MIM model is?

[pmaria]

@architolk schreef: bij mim:View speelt overigens iets soortgelijks: een mim:View gaat over een mim:Objecttype in een ander model, maar wat er vervolgens in de mim:View staat heeft waarde op zichzelf. Een mim:View lijkt op een sh:NodeShape, waarbij dan de sh:targetClass verwijst naar het oorpronkelijke mim:Objecttype. Maar dan heeft mim:View dus eigenlijk twee URI's nodig: hoe doe je dat???

Dit is een algemeen probleem met de huidige LD bindings in MIM. Naar mijn idee moeten we een veel duidelijker onderscheid in conceptueel en logisch model gaan maken om dit te verhelpen. Dat zou dan ook wat betekenen voor welke metegegevens je op wel soort model kunt hanteren. Hopelijk kunnen we dat in een volgende major versie van MIM gaan tackelen.

[pmaria]

Ik heb het idee dat we in het huidige voorstel op twee benen hinken. We proberen met deze metagegevens aan de ene kant LD neutraal te zijn, door het introduceren van een URI (soort van) identificerend is voor het modelelement. Aan de andere kant willen we hiervan gebruikmaken om ontologie en shapes vorm te geven. Echter, eigenlijk missen we nu dan nog metagegevens om de identificaties van shapes te kunnen realiseren. Maar, als we die ook gaan toevoegen wordt het geheel meer een set metagegeves toegespitst op de LD binding. Ook dit heeft te maken met mijn vorige comment - het onvoldoende onderscheid tussen conceptueel en logisch model in MIM. Als dit onderscheid er wel was, dan zou je de URI op conceptueel niveau kunnen gebruiken voor een ontologie-element, en de URI op logisch niveau kunnen gebruiken voor een shape-element.

De vraag is wat nu wijsheid is.

[architolk]

@architolk schreef: bij mim:View speelt overigens iets soortgelijks: een mim:View gaat over een mim:Objecttype in een ander model, maar wat er vervolgens in de mim:View staat heeft waarde op zichzelf. Een mim:View lijkt op een sh:NodeShape, waarbij dan de sh:targetClass verwijst naar het oorpronkelijke mim:Objecttype. Maar dan heeft mim:View dus eigenlijk twee URI's nodig: hoe doe je dat???

Dit is een algemeen probleem met de huidige LD bindings in MIM. Naar mijn idee moeten we een veel duidelijker onderscheid in conceptueel en logisch model gaan maken om dit te verhelpen. Dat zou dan ook wat betekenen voor welke metegegevens je op wel soort model kunt hanteren. Hopelijk kunnen we dat in een volgende major versie van MIM gaan tackelen.

Eens. Mijn voorstel zou zijn om de URI te koppelen aan het originele modelelement, dat lijkt ook het beste aan te sluiten op de bestaande werkwijze. Voor de Shape maken we dan sowieso gebruik van de afleidingsconstructie, zoals ook al beschreven was in de originele opzet.

[architolk]

Ik heb het idee dat we in het huidige voorstel op twee benen hinken. We proberen met deze metagegevens aan de ene kant LD neutraal te zijn, door het introduceren van een URI (soort van) identificerend is voor het modelelement. Aan de andere kant willen we hiervan gebruikmaken om ontologie en shapes vorm te geven. Echter, eigenlijk missen we nu dan nog metagegevens om de identificaties van shapes te kunnen realiseren. Maar, als we die ook gaan toevoegen wordt het geheel meer een set metagegeves toegespitst op de LD binding. Ook dit heeft te maken met mijn vorige comment - het onvoldoende onderscheid tussen conceptueel en logisch model in MIM. Als dit onderscheid er wel was, dan zou je de URI op conceptueel niveau kunnen gebruiken voor een ontologie-element, en de URI op logisch niveau kunnen gebruiken voor een shape-element.

De vraag is wat nu wijsheid is.

Het is niet alleen het verschil tussen conceptueel en logisch (MIM-2 en MIM-3), maar ook het onderscheid tussen modelelementen en modelelementbesichrijvingen. Voor mijn gevoel doen we het meeste recht aan MIM als we de URI beschouwen als de identificatie van het Modelelement (en dus niet zijn beschrijving). Merk op dat de UUID in EA ook hetzelfde blijft over versies van modellen heen.

[Bakkej]

@Bakkej schreef: In MIM-LD heeft isGedefinieerdIn als range owl:Ontology. Is dit handig of liever mim:Package, of mim:Informatiemodel (EN/)OF mim:Domein

@architolk schreef: Ik denk idd dat we in MIM-LD de range van mim:isGedefinieerdIn moeten aanpassen. Deze was oorspronkelijk denk ik geïnspireerd op rdfs:isDefinedBy, vandaar de betreffende range. Maar nu is meer duidelijkheid over packages, en kunnen we hem daaraan koppelen. Lijkt me idd OF mim:Informatiemodel OF mim:Domein.

Wat doe je als je voor een modelement een URI gebruikt van een bestaande standaard? Moet je dan isGedefinieerdIn invullen? Zo ja, wat is dan de waarde, als dit geen MIM model is?

In principe moet je altijd isGedefinieerd invullen, Meestal is het echter vrij goed automatisch te doen, zeker voor modelelementen die je zelf definieert.. Wanneer een modelelement uit een externe standaard komt kan het wat lastiger zijn. Als het modelelement een URI heeft, dan heeft het informatiemodel vast ook een URI. Dit hoeft geen MIM model te zijn (is sowieso natuurlijk alleen een manifestatie). LD modellen hebben altijd wel een URI. Als er echt geen URI is voor een model kan je natuurlijk altijd zelf een mim-model maken. Dit is ook wat we soms al doen.. (denk aan de mim-datatypen die we mappen naar de xsd-datatypen of GML, welke beide wel een URI hebben.. e.g. voor GML: https://def.isotc211.org/ontologies/iso19136 of http://www.opengis.net/gml/3.2/)

Misschien is dat niet echt een antwoord op je vraag. Ik zou dit willen lezen als een rdfs:range (alles wat we invullen moet dan wel ee een mim:informatiemodel zijn ) en niet als sh:class (alles wat we invullen moet (expliciet) een mim:informatiemodel zijn).

[Bakkej]

Ik heb alles verwerkt waarvan ik denk dat het in het huidige MIM past. Dit is geen waterdichte beschrijving van alles wat we nodig hebben. Er is meer duidelijkheid nodig over MIM-2 en MIM-3 en deze niveau's moeten we ook bewuster gaan toepassen. Het is nog steeds de vraag wat een modelelement precies is en hoe dit zich verhoudt tot bijvoorbeeld een rdfs:Class of een sh:PropertyShape. Dit hangt ook sterk samen met het feit dat we één modelelelement meerdere keren kunnen beschrijven. Denk maar aan in hoe veel modellen nen3610:identificatie gebruikt wordt. Dit zijn zaken die we vermoedelijk pas helder kunnen krijgen in een versie 2 van MIM.

We kunnen nu in ieder geval een modelelement uniek identificeren met een URI. Deze URI wordt in Linked data gebruikt om de betreffende RDFS-term te identificeren. Voor het munten van een URI voor een sh:Node zijn geen specifieke metagegevens geintroduceerd.

[Gtrouborst]

Is deze pull request klaar om gemerged te worden?

[pmaria]

@Gtrouborst Nee moet nog gereviewd worden

[pmaria]

@PalmJanssen @lennartvanbergen lijkt me goed als jullie ook reviewen, in ieder geval het algemene deel.

[PalmJanssen]

Het lukt mij niet om hierin op jullie vlieghoogte te komen en daarnaast heb ik vertrouwen dat het goed komt. Wel heb ik dit punt: Wat mij betreft is deze uri zaak alleen nodig als je een vocabulaire en of een ontologie en mogelijk shapes wilt maken. Als je dat wil dan moet je daar zuiver in zijn en ook dingen verplichten, maar (raar maar waar) het komt ook voor dat je dat niet wilt. Ook dat moet kunnen. Dus wat mij betreft is dit verhaal conditioneel.

[pmaria]

@Gtrouborst werk is voldoende om te mergen. De plaatjes moeten in zowel metamodel UML als in metamodel LD nog aangepast worden , en de ontologie moet geupdatet worden. Ik stel voor dat we dit meenemen in een losse actie voordat we officieel de standaard releasen. Dit moet namelijk ook nog gebeuren voor een aantal andere constructen die geintroduceerd of gewijzigd zijn.

[Gtrouborst]

@pmaria: fijn dat dit gelukt is!

[lennartvanbergen]

De identificatie van een modelelement in een model: laten we die niet URI noemen, maar modelelement identificatie (waar je een URI in invult).

[PalmJanssen]

Heb nu bij de metaklasse modelelement de tagged value Modelelement identificatie opgenomen:

[ThiesMesdag]

Hiervoor PR #500 gemaakt