MIM serialisatie: waardelijsten die buiten het model gespecificeerd zijn, geef de specificatie hier ook van

[lennartvanbergen]

Codelist en referentielijst zijn vaak buiten het model gespecificeerd. Geef ook hier de specificatie van mee met de MIM export.

Een referentielijst doet dit al (mits echt gedaan in het informatiemodel) maar voor codelist is het raden.

Bv. laat codelist extenden van referentielijst, of neem de structuur van de codelist ook op in het informatiemodel of in een extensie of ... iets/ergens (!).

[lennartvanbergen]

@PalmJanssen Deze lijkt me iets voor Geonovum, aangezien G de enige is die codelist gebruikt.

[lennartvanbergen]

Waar specificeer je de waardelijst en de structuur van de waarde, als aanwezig:

• niet, want niet nodig voor data uitwisseling, de eigenschap met een gegeven erin volstaat
• - in het informatiemodel
• in een specificatie die een aanvulling is op het informatiemodel

De betekenis specificeer je bij de waardes elders. De betekent van de eigenschap dit dus wel in het informatiemodel, de betekent van de waarde zelf niet. Soms helemaal niet, bv. gemeente deventer, gemeente utrecht, hebben geen definitie nodig. Maar bv. bij type openbare ruimte - bv. plein - is de betekenis wel van belang.

En hoe vertaalt zich dit naar:

• wat modelleer je in het IM? --> de betekenis zit in de eigenschap, de structuur van de data ook.
• wat wissel je uit?
• wat heb je nodig voor model-gedreven werken?

Wanneer moet je de hele waardelijst, dus code, waarde, en ook beschrijvende gegevens zoals definitie en toelichting, helemaal weten omdat je dit wilt gebruiken?

• dropdown lijstjes
• een code krijgt en je toont deze in het scherm, en de gebruiker wilt weten wat UUID1224 is.

De identificatie van de waarde bij een codelist en referentielijst is nodig in de data uitwisseling.

• Voor model-gedreven werken is de waarde zelf: wel nodig.
• Voor model-gedreven werken is de definitie van de waarde: niet nodig.

Het punt voor ontwikkelaars is dat de specificatie van de waardelijst nu niet in het informatiemodel te vinden is en als je meer nodig hebt dan de code en/of de waarde dat je nu geen specificatie krijgt van de extra (meta) gegevens.

Denk aan: de locatie van de waardelijst staat in het informatiemodel. Daar kan je de specificatie opvragen, bv. /locatie/mim-export.xml van sec de waardelijst ...

Denk aan: altijd een referentie lijst gebruiken als je meer wilt vertellen in het informatiemodel, en dan alle relevante "kolommen" opnemen.

zie ook: https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/address-type

[lennartvanbergen]

Gezien codelist vooral door GEO wordt gebruikt verwachten we hier vooral een voorstel vanuit Geonovum.

Optie 0: niks doen Per IM, via documentatie, bv in een extra PDF bij het IM. Dit is niet de behoefte van model-driven software developement.

Optie 1: modelleer altijd een referentielijst, en neem hier de specificatie op van de data die voor je informatiemodel van belang is.

Optie 2: los het op voor (alleen) codelist (immers Enumeratie is al duidelijk en Refentielijst kan al duidelijk gemaakt worden). Spreek dus af dat bij codelijst dat het gaat om:

Een codelijst is in mijn informatiemodel:

• een uitbreidbare enumeratie met alleen waardes --> als enumeratie te implementeren, oftewel string (dit gaat dan goed).
• een lijst met codes en waardes --> hier is meer nodig
• een lijst met codes --> hier is meer nodig

Dus, een metagegeven bij codelist: type codelist: die je kan vullen met 1 type, uit: code, waarde, of codewaarde.

Als hier 'waarde' staat: klaar, IM bevat voldoende informatie.

Als hier 'code' of 'code en waarde' staat: dan nog een extra metagegeven bij elke aparte codelist van-code-naar-waarde-specificatie : uitleg/specificatie hoe de waarde te vinden is, beschreven in tekst. Bv. Neem de locatie URI van de codelist en zet hier /{code} achter, je krijgt dan de waarde --> codelist locatie = http://mijndomein.nl/waardelijsten/mijnwaardelijstnaam en code = 6 den ga daar op zoek naar het veld 'X' --> http://mijndomein.nl/waardelijsten/mijnwaardelijstnaam/6?format=JSON --> "iets" met property "X" en in X staat "6":"fiets" --> als 6 in je data staat, dan is de waarde 'fiets'.

eventueel nog: waardelijst standaarden: die je kan vullen met 1 of meerdere uit: SKOS, Genericode, en eventueel nog een paar.

Beschrijf dit in MIM of in een extensie en geef een metagegeven op om welke variant het gaat.

Optie 3: beschrijf goed waar je de specificatie van de externe waardelijst kan vinden en hoe je die kan ophalen en met software kan verwerken - als software (zonder menselijke tussenkomt). De waardelijst heeft al een locatie, maar dat is de locatie van de waardelijst zelf en niet van de specificatie van de waardelijst.

Kunnen de organisaties die vooral codelijst gebruiken hierin de lead nemen? Zij lopen immers hier vooral tegenaan.

[lennartvanbergen]

Voor codelist = de gewone uitbreide enumeratie gaat alles goed.

voor codelist = de andere 2 waar meer voor nodig is, voorstel wordt nader uitgewerkt door Geonovum.

[PalmJanssen]

Ik maak eerst even een overzicht van de CodeList zoals gedefinieerd in ISO19103 (conceptual schema language) ISO19109 (rules for application schema) INSPIRE D2.7 Encoding rules.

Daarna een voorstel voor MIM.

overzicht

\<\> is a flexible enumeration that uses string values for expressing a list of potential values.

A code list can be used to describe an open enumeration.

Requierment: Code lists shall be used if none or only a few of the allowed values are known, like a likely set, or an initial set.

Code lists can furthermore be divided into several types, for example those that are managed by a single authority and those that can be extended by a user of the schema.

Code lists managed by a single external authority may carry a tagged value “codeList” whose value references the actual external code list. If the tagged value is set, only values from the referenced code list are valid.

Recommendation 4. The value of the tagged value “codeList” should be a persistent URI identifying the code list.

Each item in the codelist contains a unique value (name or code) that all software will use to recognize the unique concept or option defined in a row of a codelists table. While numbers may be used, simple name identifier values are encouraged to enable human understanding of the code; this value need not be a proper name in any language;

Each code should have a unique unambiguous definition and describe a unique concept or option that supports the intent of the definition;

Codelists and their associated definitions are controlled in registers.

uit 19109: metamodel Conventionally a vocabulary was considered as a set of character string values. However, modern knowledge organization theory considers a term to be merely a label for a concept.

The code list and each of its values shall be denoted by a persistent identifier, such as a URI; All values of a code list shall be available, including those that have been deprecated, retired or superseded.

INSPIRE encoding rules: Recommendation 19 URIs should be used to encode code lists and their values in INSPIRE code list registers and to reference such items. The URIs should use the following structure:

• http://inspire.ec.europa.eu/codelist/ for code lists
• http://inspire.ec.europa.eu/codelist// for code list values

Recommendation 20 When specifying a code list value in instance data, a human-readable label to be used in user interfaces should be provided in addition to the unique identifier of the value.

EXAMPLE In GML, the value identifier and label for the country code (code list id: CountryCode) for Germany (value id: DE) would be encoded using the xlink:href and xlink:title properties: \ \ (…) \

Open issue 3: There is a distinction between the identifier of a concept and the identifier of an item in a register. Following the rules of 19135, if the definition of this registered item is changed by the control body then the old item is superseded and a new item - with a new identifier - is created. In the terminology of ISO 19135, a registered code list value item is different from the underlying 'concept', i.e. multiple code list value items with supersession relationships may represent the same concept, which in turn may also be identified by a URI. This aspect is currently lacking in ISO 19135. It is recognised in 19135 in the last paragraph of 7.5, but ISO 19135 currently does not support an identifier for a concept. However, this topic is discussed in the current revision of ISO 19135.

voorstel voor Codelijst in MIM

[ArjanLoeffen]

@PalmJanssen Zie ik het goed dat je nog geen voorstel hebt geformuleerd?

[PalmJanssen]

Moet ik nog doen

[PalmJanssen]

Mijn voorstel is om de codelijst eenvoudig te houden ongeveer vergelijkbaar met de ISO toepassing: <<CodeList>> is a flexible enumeration that uses string values for expressing a list of potential values.

A code list can be used to describe an open enumeration.

Requierment: Code lists shall be used if none or only a few of the allowed values are known, like a likely set, or an initial set.

Wel met twee toevoegingen:

1) de toevoeging dat een Codelijst buiten het model wordt beheerd. (en daar dus tagged values voor moet hebben). 2) de TV's zijn:

• Locatie: de locatie (denk altijd URI of URL) van de codelijst
• Doel formaat: het format waarin de waarden gepubliceerd zijn. Mogelijk een lijst opnemen van voor de hand liggende formaten: SKOS, CSV, ?
• Datatype: datatype van de waarde. Een primitief type zoals bijvoorbeeld ChararcterString, Date, Integer, etc.
• Waarde item: het item (of element) van de lijst dat de waarde representeert. Bijvoorbeeld pref label, label (UK), landnaam, landcode, enz

Een codelijst heeft dus geen structuur gedefinieerd in het model maar kan wel een structuur hebben, maar die is dan extern bepaald.

Als je structuur in de codelijst wil definiëren dan moet je een <<Referentielijst>> gebruiken.

We moeten denk ik wel iets opnemen over de referentie naar waarden in een codelijst. Voorstel is om dat met een URI te doen die bestaat uit de locatie van een codelijst (TV:Locatie) en de waarde. Dus uri = locatie/waarde. Bijvoorbeeld: www.auto.nl/automerken/mercedes

[PalmJanssen]

Voeg toe:

Profielspecificatie: Referentie naar het profiel dat de implementatie beschrijft.

Opmerking: MIM kan een aantal standaard profielen beschrijven. Bijvoorbeeld: Inspire toepassing, genericode.......

[lennartvanbergen]

eens

[PalmJanssen]

Tekstvoorstel:

Een codelijst wordt gebruikt voor de specificatie van een open waardelijst, een waardelijst waarin geen of nog niet alle waarden zijn gespecificeerd. Daarnaast geldt:

• Een codelijst is altijd extern aan het model gespecificeerd en beheerd.
• Een codelijst heeft geen structuur gedefinieerd in het model maar kan wel een structuur hebben, maar die is dan extern bepaald.

Als je structuur van een codelijst in het model wilt definiëren dan moet je een <<Referentielijst>> gebruiken.

Een codelijst heeft een aantal tagged values:

Locatie (1): de locatie (vaak een URI of URL) van de codelijst Doelformaat (1): het format waarin de waarden gepubliceerd zijn. Mogelijk een lijst opnemen van voor de hand liggende formaten: SKOS, CSV, ? Datatype (1): datatype van de waarde. Een primitief type zoals bijvoorbeeld ChararcterString, Date, Integer, etc. Waarde item (0..1): het item (of element) van de lijst dat de waarde representeert. Bijvoorbeeld pref label, label (UK), landnaam, landcode, enz. Alleen ingevuld als de codelijst een structuur heeft. Profielspecificatie (0..1): Referentie naar het profiel dat de implementatie beschrijft. Opmerking: MIM kan een aantal standaard profielen beschrijven. Bijvoorbeeld: Inspire toepassing, genericode.......

[ArjanLoeffen]

Vanuit het perspectief van Imvertor: die tagged values moeten nog worden toegevoegd en de beoogde functionaliteit worden beschreven en geïmplementeerd.

[PalmJanssen]

Opmerking: Ik stel voor om bij een codelijst niet op te nemen dat het per definitie een openlijst is. Het enige dat telt is dat het een extern gepubliceerde lijst is.

[PalmJanssen]

Blijft als openlijst

[dkrijtenburg-GNM]

@PalmJanssen : kan deze worden gesloten nu de IMIM-serialisatie is opgeelverd?

[PalmJanssen]

\nee dit is een issue voor de MIM 1.2

[PalmJanssen]

Paul Verifieert hoe dit nu in het mim tekstdoc staat en past aan wat nog nodig is.

[PalmJanssen]

laatste kennis verwerkt in pull request #341

[Gtrouborst]

Aanpassingen zijn opgenomen in de werkversie