Geonovum / MIM-Werkomgeving

Werkomgeving van MIM. Bevat werk en alle pre-publicatieversies.
https://geonovum.github.io/MIM-Werkomgeving/
8 stars 15 forks source link

issue 188 'URI van model en modelelementen voor publicatie op het web' #306

Closed ThiesMesdag closed 1 year ago

ThiesMesdag commented 1 year ago

Metagegevens

Bakkej commented 1 year ago

Wat nog mist is de metagegeven "URI", toepasbaar voor ieder modelelement. De URI is de identificatie van een modelelement. Dit kunnen we opbouwen op basis van de Basis-URI samen met de naam van het modelelement (op logisch niveau conform de naamgevingsconventies. In de meeste gevallen zal een modelleur dit metagegeven daarom niet invullen. In sommige gevallen kan de URI van een modelelement niet bepaald worden aan de hand van de basis-URI van de bijbehorende package en de naam van een modelelement. Bijvoorbeeld als gevolg van de gekozen URI-strategie of wanneer een attribuutsoort uit een ander informatiemodel hergebruikt wordt (e.g. nen3610-2022:identificatie). In dit geval zal de modelleur het metagegeven URI wel invullen.

Voorstel: toevoegen metagegeven URI

#### Metagegeven: **URI**

>   **Definitie URI**  
>   De identificatie van een modelelement.

*Toelichting* De URI kan een urn-URI (<urn:object:Pand> of een http-URI (<http://.../def#Pand) zijn. De URI kan bepaald worden aan de hand van de naam van het modelelement en de basis-URI van de package waarin het modelelement zich bevindt. 

*Toepassing*: alle modelelementen

Het metagegeven URI is óók van toepassing op packages. Voor de package van het type Informatiemodel moet de URI altijd ingevuld worden, omdat er geen bovenliggende package is waarvan de basis URI gebruikt kan worden. Voor domein en view packages gelden dezelfde regels als voor andere modelelementen.
Ontologie-URI is hiermee overbodig omdat deze informatie middels het metagegeven URI beschikbaar is.

Voorstel: verwijderen metagegeven Ontologie-URI

De metagegevens URI en Basis-URI zijn universeel toepasbaar. Schema-URI en Schema Basis-URI lijken vooral gebruikt te gaan worden voor LD-publicatie. Dit omdat SHACL een MIM Niveau 3 taal is; Als we kijken naar XSD en JSONSchema is dit het model van Niveau 4 (in LD is het model van niveau 4 RDF (niet SHACL)). Ook in UML is het logisch om het schema individueel te kunnen identificeren; het schema is namelijk niet onlosmakelijk verbonden aan een objecttype (of meer andersom; een objecttype is niet onlosmakelijk verbonden aan één schema). Denk bijvoorbeeld aan een objecttype die ook in een viewpackage voorkomt met een kleinere set eigenschappen. Er is geen sprake van een nieuw type object, wel van een nieuw schema.

Het model moet gebruikt kunnen worden zonder dat er vastgestelde (http-)uri's beschikbaar zijn (bijvoorbeeld tijdens de ontwikkelfase). In dit geval kan een urn op basis van de package alias en het modelelement naam bepaald worden (zoals er nu ook over modelelementen gesproken wordt. Mogelijk kunnen we hiervoor moet een default waarde bepalen.

Voorstel: default waarde voor de basis URI van een package is "urn: + informatiemodel.naam" Als we bijvoorbeeld het MIM in MIM beschrijven kunnen we het volgende krijgen: . Of, door een baseURI in te vullen kunnen we bijvoorbeeld http://bp4mc2.org/def/mim#Objecttype krijgen.

De toelichting van basis-URI klopt niet helemaal. We willen bijvoorbeeld niet (vanuit de MIM-standaard) voortschrijven of een URI een slash- of hash-URI moet zijn. Dat maakt in essentie namelijk niet uit.

Voorstel wijzigen toelichting bij Basis URI.

*Toelichting* Een uniform resource identifier (URI) is een compacte reeks tekens die een abstracte of fysieke bron identificeert. Een basis-URI is een het gemeenschappelijke deel van deze reeks tekens die voor alle elementen in het informatiemodel geldig is. Dit metagegeven is verplicht. De basis-URI bevat altijd een 'scheme', dit kan bijvoorbeeld "http://" of "urn" zijn. En voldoet aan een gekozen URI-strategie.

Daarnaast speelt herkomt een rol. Nu informatiemodellen (en andere packages) een duidelijke identificatie hebben kunnen we dit gebruiken om naar het definierende informatiemodel te verwijzen (voor modelelementen in een viewpackage is dit altijd noodzakelijk). Dit heeft een overlap met het metagegeven herkomst, echter is het daar toegestaan om ook naar andere dingen te refereren zoals een registratie en is er geen sprake van een directe koppeling want het is een vrij in te vullen veld. Het is dus niet simpelweg de inverse van mim:bevatModelelement. Bijvoorbeeld een viewpackage kan een objecttype bevatten maar het is altijd een domein package die het objecttype definieert; en deze relatie willen we expliciet hebben. In Linked data komt dit overeen met rdfs:isDefinedBy. In principe heeft dit geen impact op bestaande modellen; de waarde voor 'is gedefinieerd in" is standaard de package waarin het modelelement zich bevindt. Voor bestaande modellen kan dit dus geautomatiseerd ingevuld worden. Alleen in een afwijkende situatie dient dit ingevuld te worden.

Voorstel is om 'isGedefinieerdIn' te introduceren

#### Metagegeven: **is gedefinieerd in**

>   **Definitie is gedefinieerd in**  
>   De package waarin het modelelement gedefinieerd is. 

*Toelichting* De definierende package is meestal de package die het modelelement bevat. De waarde voor dit metagegeven kan wanneer dit het geval is afgeleid worden. In afwijkende situaties moet de URI van de betreffende package ingevuld worden. Een view package definieert nooit de modelelementen die het bevat, dit is altijd een ander domein package. Het verschil met het metagegeven herkomst is dat dit een directe verwijzing is naar een informatiemodel of een package daarbinnen. 

*Toepassing*: alle modelelementen

Als laatste hebben deze metagegevens effect op de transformatie naar LD Dit zal ook nog gewijzigd moeten worden, is dat iets voor deze PR?

pmaria commented 1 year ago

Als laatste hebben deze metagegevens effect op de transformatie naar LD

Dat leek me zeker iets voor deze PR. Alleen is deze nu al gemerged. Het zou wel opgenomen moeten worden voordat er een nieuwe release gemaakt wordt.

Gtrouborst commented 1 year ago

@pmaria: Klopt de request was approved, maar dit lijkt mij een belangrijk punt.

@ThiesMesdag & @PalmJanssen: Geldt daarnaast niet hetzelfde voor (de tabellen in) hoofdstuk 3 - Metamodel in UML en hoofdstuk 4 - Metamodel in Linked Data en de diagrammen in bijlage 6.1?