Dit element zou ik ook graag in het lineage model terug willen zien. Is het altijd een onderwerp van gesprek. Ik zie een realisatie bron en een realisatie doel

een hoger MIM beschouwingsniveau wordt benoemd;

De betekenis hoeft niet altijd hetzelfde te zijn. Je kan toch ook een related op een zelfde niveau hebben.

Zou die hele tekst vervangen door: horizontaal geeft aan dat er een semantische relatie tussen modelelementen binnen het zelfde beschouwingsniveau is. Meestal zal dit niet tussen modelelementen binnen één model maar binnen verschillende modellen zijn.

voeg toe attribuut: type semantische relatie: exact, gerelateerd enz.

moet ik even over nadenken. Zijn dit niet verschillende dingen? Leg dat uit.

wat doen we met een modelelement op een MIM 3 niveau dat een samenstelling is van twee elementen op een MIM 2 niveau? Tussen 2 en 3 zie ik meer een realisatie relatie.

voeg toe: elk modelelement in elke MIM laag,

Voeg toe. Merk op dat de semantische lineage in deze context de elementen uit modellen op de verschillende MIM lagen met elkaar verbindt. We spreken daarom over verticale semantische lineage.

laten we de titel dan 'Semantische lineage' noemen.

Opmerking, ter info: Zelf zou ik de conditie niet snel op het waardetype zetten maar op het attribuuttype.

Opmerking: Is dit niet een makkelijker te begrijpen verschil tussen objecttype en categorie? Een categorie gebruik je om binnen een objecttype subtypen aan te duiden zonder dat daarvan specifieke kenmerken van belang zijn (binnen het beschouwingsdomein).

Is het niet een noodzakelijke voorwaarde die moet gelden voor een attribuuttype?

Dat zie ik niet. Kan een attribuuttype ook kenmerken hebben?

Hier komt mijn punt weer. Onderkennen we dat << Persoon>> een attribuuttype heeft met de naam werkgever van het type <<Organisatie>>

Krijgt een dergelijke lijst een typering mee? Lijst van domeinobjecten? Ik vraag me af of dit nodig is. Binnen de context van een beschouwingsdomein is een ding een domeinobject of niet. Buiten de context kan misschien alles wel een domeinobject zijn.

lijkt meer op een metagegeven van een gegevenstype

Vraag: dus niet de sleutel van het Gegevensobject zelf?

Vraag: Is er ook gedacht aan een gestructureerd waardetype waarbij attribuuttypen gegroepeerd worden? Bijvoorbeeld: Attribuuttype Landbouwperceel.gewasEnOppervlak.GewasEnOppervlak

GewasEnOppervlak: - typeGewas - oppervlak

vraag? waarom categorie en geen objecttype?

hetgeen dat waar is

Interessant maar ik kan een data instantie toch herkennen aan zijn type? Type is als het ware een ingebakken kenmerk.

Staat dat ergens? Ik ga er niet zomaar van uit dat subtypen mutual exclusive zijn. Met een constraint kan je het wel aangeven.

Vraag. Is dat altijd zo? Is 'gewicht tussen 0 en 5 kg' een categorie? Zo ja kan het ook een domeinobject zijn?

Opmerking: kan dit niet weg? Een Weg uit de Categorie 'snelweg' leidt toch tot de voorkomens Snelwegen uit de populatie Wegen? Dit wordt naar ik meen ook in de volgende zin gezegd.

Opmerking: precies! afzonderlijk is het woord

waar we specifieke informatie over wensen

het is eerder, voor mij, dat ik van een fiets andere kenmerken wel weten of vastleggen dan van een auto. Het hoeven in het beschouwingsdomein geen onderscheidende kenmerken te zijn.

is identificatie dmv beschreven kenmerken altijd van belang? Ik denk het niet. Ook niet voor de inwinning. Een mens kan je herkennen aan zijn fysiek voorkomen terwijl in een model geen enkel kenmerk daarover gaat.

welke soorten/type domeinobjecten er zijn binnen een bepaald beschouwingsdomein.

kan weg

Opmerking: Begrijp ik en is een heel goede methode maar....hangt dit niet van je 'implementatie' af? 'eenvoudige' modellen kunnen best categorien uit een 'simpele afgesproken lijst' halen en die gebruiken als waarde van een attribuut, zonder dat er verwijzingen zijn.

Een opmerking: Gegevens inwinnen is mogelijk weer een ander aspect dan gegevens specificeren. Het specificeren van sleutels in relaties gebeurt niet altijd in een model en is soms expliciet in de zin dat je zelf mag weten hoe je dat doet. Maw een sleutel definieren is optioneel

is hier een definitie van (nodig)?

Dat kan omdat ze alle hetzelfde (hoofd)onderwerp hebben, maar die regel is er niet.

zo zie ik dat ook

Voor mij moeilijk. Ik weet niet of we dit onderscheid moeten maken. Hebben we het nodig. Lijkt alsof een Klasse een definitie heeft en geen eigenschappen en bij een objecttype andersom.

In UML is een klasse: In UML, a class represents an object or a set of objects that share a common structure and behavior. Classes, or instances of classes, are common model elements in UML diagrams. A class identifies the attributes, operations, relationships, and semantics that instances, or objects, of the class possess.

Voor het beschouwingsdomein is een Class een objecttype, voor het het verwerkingsdomein is een Class een Gegevensobjecttype

Maar het gaat wel eisen stellen aan een technische structuur. Een gegeven en onderwerp zijn aan elkaar gekoppeld en Gegevens aan Gegevensobject. In UML gaat dat niet lukken. Het Gegevensobject is daarin het onderwerp van alle gegevens.

mij is hier even niet duidelijk waarom een classificatie niet ook een kenmerk is. 'appelsoort', is een classificatie en ook een kenmerk.

Ah ik denk dat ik het nu snap. Een classificatie is het toekennen van een klasse aan een object: jij, [Jan], ben een Persoon. Dat is als het ware ook een eigenschap.

dit lijkt wel erg veel op wat UML doet met een binding van een klasse dmv een attribuut ipv een associatie(rol). Waarom noemen we dit?

Ah ik denk dat ik het nu snap. Een classificatie is het toekennen van een klasse aan een object: jij, [Jan], ben een Persoon. Dat is als het ware ook een eigenschap.

hier aan toevoegen ? dat omdat het onderscheidbaar is het ook aanwijsbaar moet zijn een dus een identiteit heeft.?

kan weg

kan weg

Is het informatieobject nodig? Het voegt denk ik niets toe aan de MIM context. Het lijkt hier dat een informatieobject een samenvoeging is van gegevens met een bepaald informatiedoel. Waarom zou je dat doen en wat maakt ze anders dan de gegevensobjecten in de context van het modelleren?

waarnemingen

benoemde?

kan weg

elektronisch

elk

kunnen het ook meerdere waarden zijn? De eigenschap 'kinderen in de klas' levert een set met meerdere namen op. Tenminste daar kan ik voor kiezen.

aha. Een kenmerk is dus een eigenschap van een instantie. Ik, Paul, heb dus geen eigenschappen maar kenmerken.

willen we in een CIM wel niet intrinsieke eigenschappen. Een chassisnummer kan ik me in CIM wel voorstellen een BSN nummer minder. Maar je zou het een administratieve view op de werkelijkheid kunnen noemen. Al is een administratieve view misschien per definitie logisch omdat het wil administreren (is gegevens)

mooi, maar het kan zowaar ook met zichzelf zijn. Voorbeeld, je eigen baas zijn.

maar

van wat

concreet aanwijsbaar. (hij hoeft niet levend te zijn)

Liever een voorbeeld als 'bankrekening' of 'abonnement'.

Een object kan heel concreet en fysiek zijn zoals een gebouw, een voertuig, het kan ook administratief of virtueel zijn zoals een bankrekening, een bitcoin.

interessant maar we hebben het hier toch al over metamodellen. Ons beschouwingsdomein is al de verschillende modellen.

😍

een geboortedatum heeft

zwart?

eh... de werkelijkheid bestaat wel maar bekeken door de mens zijn er vele.

jouw

over

alles

heb moeit met woord typisch. Het is niet hetzelfde als typerend maar wat is het wel?

voeg toe wat en waarvoor een metamodel is.

Bijvoorbeeld: Het gaat daarbij over regels voor het opstellen van een model, een model van een model.

over wat

deze heeft mijn voorkeur

de term gegevensdomein is denk ik duidelijker. Met gegevens kan je vervolgens van alles doen: verwerken

een gedachte: is dit concrete BSN nummer niet ook een concrete instantie, dus blokhaken?

kan weg

Is een begrip niet een term met een betekenis? Dat onthouden mensen beter. Kan dat niet hierbij.

Voeg toe: Nu we deze vijf typen modellen benoemd hebben, bedenk dat al deze typen abstracties zijn van de werkelijkheid en dat ze in gezamelijkheid leiden tot een compleet maar nog steeds abstract beeld. Er is ook een afhankelijkheid van beneden naar boven, een fysiek datamodel kan niet zonder een logisch gegevensmodel, kan niet zonder een conceptueel model, kan niet zonder een model van begrippen, kan niet zonder kennisbronnen en verhalen.

talig

de werkwijze is misschien niet eenduidig, het resultaat moet dat wel zijn. ... modelleren is juist een werkwijze om een eenduidige beschrijving te maken .....

😊👌

In de inleiding staat betekenis op twee manieren: 1) betekenis geven aan gegevens door er waarde en gevolg aan te verbinden en 2) en betekenis in de vorm van semantiek.

Neem op dat in het proces van gegevens delen het kennen van de betekenis van de gegevens een voorwaarde is voor informatiedracht.

Wet en regelgeving wordt hier al vrij prominent benoemd, alsof dat de context van het hele doc bepaald. Dat lijkt mij niet terecht. Neem op dat betekenis essentieel is in gegevensdelen. Zonder betekenis kan je geen informatie maken van gegevens. Wet- en regelgeving neemt daarbij een bijzondere plaats in .......... (is dat trouwens wel zo? Het plaatst alleen gegevens en informatie in een juridische context..... is dat anders dan welke context dan ook?)

Neem hierbij op: Bedenk dat de mens dingen definieert (of ziet) om er over te kunnen praten. Een ding wordt als het ware geïdentificeerd en gedefinieerd omdat de mens dat in de communicatie en zelfs denkwereld nodig heeft. Een ding wordt dus altijd bezien door een 'menselijke' bril.

opgenomen worden via de hypothesis webannotatie of sturen naar p.janssen@geonovum.nl

ik zou dit doen: Adres.geolocatie [0..1]. Een adres kan optioneel een geolocatie hebben

zelfs

gestructureerd

reguliere expressie

Hoort hier niet. Is een apart modelelement.

dit is ook een datatype, kan bij type hierboven worden opgenomen. Noem het Keuze(datatypen)

waarom staat die eigenlijk hier? Een objecttype kan keuzeattributen hebben maar ook attribuutsoorten, gegevensgroepen, relatiesoorten etc. Dit is de structuur van het metamodel.

dit is moeilijk te begrijpen. helpt dit?: aandrijving van fiets (ketting.type ketting of snaaraandrijving. type snaar)

is

is dit handig? De metagevens zijn eerder besproken maar in een andere context

Gaat hier eigenlijk over het informatieobject, maar dat is mogelijk iets te abstract.

De id's die ik modelleer zijn altijd bedoeld om iets in een gegevenshuishouding uniek te identificeren. De relatie naar de werkelijkheid wordt niet zomaar door een id gerealiseerd.

De attribuutsoort(en) die de unieke aanduiding realiseren zijn met het metagegeven identificerend herkenbaar bij een Objecttype opgenomen.

het woord use case of werkproces is nog niet gevallen. Maar je modelleert altijd vanuit een use case. Het functioneren van het domein vind ik een onduidelijke term.

Aanpassing naar functioneren van werkprocessen van dat domein... helpt al.

Leg het woord domein hier uit. Domein is een toepassingsgebied, een sector.....

Bijna goed voorbeeld. GML is geen model maar een implementatie. GM_Point, GM_Curve etc zijn dan ook niet van GML maar van ISO19107 Spatial Schema. Dat is wel een model.

Andere metagegevens van View zijn eerder besproken bij Informatiemodel:

package (of verzameling modelelementen). Gebruik van term domein is hier verwarrend

klopt voor 1.1. In 1.1.1 wordt dit uitgebreid

in

Dit is niet zomaar een in te vullen gegeven. Als je een model gaat maken moet je daar van te voren over nadenken. Wordt dat ergens geadresseerd in de Primer. Verwijs daarvoor ook naar MIM doc.

Hier is de context 'alle informatiemodellen'

voorbeeldwaarde

gebruiken of hebben

gebruiken of hebben lijkt me beter dan bevatten

nogal wat termen in relatie tot modelelementen en metagegevens daarvan. De modelelementen hebben veelat een relatie tot elkaar.

MIM gebruikt de term modelelementen (349 keer in de tekst)

(MDA - Model Driven Architecture) of zo je wil MDD.

Lijkt me goed om hier te noemen. (weer wat geleerd :-) )

gebruikt MIM o.a. UML als modelleertaal in de vorm van UML-klassediagrammen.

opmerking: andere talen zijn natuurlijk ook toegestaan

MIM-beheerplan

hier komt de formalisering van de taal als aspect naar voren

met deze weergave van het model

kan je hier vermelden dat er geen formele taal wordt gebruikt

met tekst, met behulp van tekst

en de inrichting van het modelleringswerkproces van organisatie van stakeholders, beschrijven van use case, opstellen model, validatie en beheer.

volgen is genoeg

Maar hier gaan we toch UML als vorm nemen?

test: Is dat correct?

test: wat gaan we hier invullen?

test: wordt dit 1.0?

test: anders formuleren