Ik zou hier niet zozeer op een CIM of LGM element willen instappen, maar juist op de expliciete ontologische verbindingen die worden gemaakt, en wat dat voor gevolgen heeft.

Ik zie in ons model de volgende ontologische verbindingen: 1. Onderscheid instantie & type; 2. Onderscheid tussen individuen en categorieën; 3. Onderscheid in domeinobject en gegeven; 4. Onderscheid tussen domeinobject en kenmerk van object 5. Onderscheid tussen domeinobject en relatie tussen domeinobjecten 6. Onderscheid tussen gegevensobject en gegeven

Een verbinding die we juist NIET leggen is: 1. Geen onderscheid tussen blote feiten (een auto) en institutionele feiten (een huwelijk, een eigendom, etc)

Waar ik wel naar benieuwd ben: als je nu naar het huidige MIM 2.0 voorstel kijkt, waar zitten dan de ontologische verbindingen? Welke zaken committen we ons aan? En als we dat weten: hoeveel schade lopen we dan op? En willen we die schade accepteren? Zie ook mijn opmerking bij tabel 3

Je hebt er nu voor gekozen om "minimale schade" te duiden in relatie tot deze FOys. Maar dat is op dit moment nog een puur filosofische overweging. In de praktijk wordt MIM niet (breed) toegepast met FOys in het achterhoofd. Alleen gUFO wordt op dit moment bekeken. Ik had eigenlijk meer verwacht dat je een andere vraag zou beantwoorden: met welke minimale schade kunnen we wegkomen? En welke minimale schade hebben we sowieso al door de ontologische verbinding die de bestaande modelleertalen veronderstellen (zoals UML, ER, FBM, ...).

Zie ook dit issue: https://github.com/Geonovum/mim-metamodel/issues/96 Daarmee wordt een bepaalde meetlat en dus ook grens gelegd. Mogelijk kunnen we dit nog aanscherpen?

Inderdaad! Overigens niet alleen voor MIM-2, maar ook in het onderscheid tussen MIM-2 en MIM-3, en de keuzes die we maken in MIM-3.

Dit is ook een belangrijk onderscheid! Je ziet dit terug in het verschil tussen een domeinobject en een categorie. Wat hier nog WEL heel interessant in is, is hoe institutionele feiten zich gedragen vanuit deze tekst (bv een specifiek eigendomrecht). Want die institionele feiten zijn m.i. dus individuen (particulars) en GEEN categoriëen.

Dit is top, en belangrijk! Want het laat het verschil zien tussen MIM-2 en MIM-3! Een objecttype ontstaat vanuit de domeinobjecten, een gegevensobject ontstaat vanuit het gegevensobjecttype. Super fijn dit!

Dit is een bepaalde aanpak, die inderdaad zeer nuttig kan zijn. Ik vraag me echter af, in hoeverre dit voor MIM relevant is. Want willen we met MIM niet juist een generiek toepasbare uitwisselingsstandaard krijgen? Ik zou dus zeggen dat in ons geval de aanpak de andere kant uit zou moeten gaan: niet van een FOy naar een domeinontologie, maar vanuit een FOy terug naar de basis-ontologie waar MIM zich (impliciet) aan commit, en daarmee je dus feitelijk beperkt in het ontologisch commitment dat je nog kunt maken over de wereld. We moeten dan accepteren dat we dit ontologisch commitment OK vinden voor MIM.

Dit lijkt sterk overeen te komen met de beschrijving die nu wordt gegeven aan een MIM-2 model en waarvoor de term "conceptueel informatiemodel" wordt gehanteerd. Zie jij dit ook zo? Is een conceptueel informatiemodel een (domein)ontologie? En andersom: is een (domein)ontologie een conceptueel informatiemodel? Indien één van deze vragen een "nee" opleveren: wat maakt ze anders?

Wat betekent in deze zin "verwerken"? Een begrippenmodel kan immers ook verwerkt worden door een computer. Ik vermoed dat het meer iets is in de zin, dat software uitspraken kan doen over het domein, of een bepaald feit kan bestaan in dat domein.

In het verleden hebben we hier ook wel eens de term "formele specificatie" voor gebruikt

Graag de volgende zin toevoegen: "we bedoelen dan ook niet met deze eigenschap dat een begrip wordt beheerd in dit begrippenkader, maar dat dit begrip valt binnen de context die met het begrippenkader wordt beoogd." (en vervolgens de zin: "Praktisch gezien kan dit..."

Deze definitie is zo langer dan SKOS en de toevoeging maakt het voor ons gevoel minder scherp. Voorstel: de tekst vanaf "(categorie van).." te vervangen door "categorisering", daarmee zou de tekst worden: "Een begrip is een eenheid van denken - idee, betekenis of categorisering".

Mijn beeld was dat het niet per sé foaf:Document hoeft te zijn, maar juist dat het 1 van deze 3 zou kunnen zijn, en wellicht zelfs nog een andere. Zolang het maar een URI is die via dct:source is verbonden met het begrip

We hebben het hier over het hoofdstuk "best practices", is dit dan wel een "regel" of meer een "leidraad" dan wel "best practices"? Daarnaast: moeten we ook nog iets zeggen over de URI? Bv wel of niet toevoegen van een owl:sameAs relatie tussen "jou" URI en de URI van de ander?

Je hebt ook nog de catalogus van de datasets zelfs (dus conform DCAT), ik denk dat je die ook moet meenemen, omdat er vaak veel verwarring is welke je nu bedoelt, en in de praktijk loopt het door elkaar.

Ik zou OF deze sectie verbeteren (zie suggestie in andere comment), OF deze sectie weghalen.

Ik zou het anders stellen: - Waardelijsten kunnen gezien worden als een verzameling van begrippen. Dan kun je van een waardelijst OF een begrippenkader maken, OF een collectie. Dat laatste is het meest makkelijk, maar het eerste gebeurt ook (wel). Vervolgens kun je gaan nadenken hoe je refereert aan het begrip. Het beste is om de URI te gebruiken, dan de code, en tenslotte de voorkeursterm.

Nou, nee... Sommige waardelijsten verwijzen naar de URI van het begrip (optimaal lijkt me), sommige waardelijsten verwijzen naar de code van het begrip (ook aardig), en slechts zelden wordt de voorkeursterm gebruikt.

Moeten we hier wel wat over zeggen? Is dit niet iets voor later? Hangt ook samen met de tekst eerder in dit stuk, over de relatie tussen ontologie en begrippenkader. Daarnaast: hierboven zeg je juist dat het MIM daarvoor een oplossing biedt. Dat is in het MIM dan ook gestandaardiseerd, en hoeven wij in principe dus niks over te zeggen (in MIM kun je dit doen door mim:begrip te gebruiken tussen een MIM modelelement en een begrip, uitgedrukt in SKOS. Als je het MIM vertaalt naar een RDF vocabulaire, wordt dan deze mim:begrip property omgezet naar dct:subject).

Dat hoeft niet. De data kan op een totaal andere manier gestructureerd zijn dan het informatiemodel beschrijft. Dit lijkt me niet juist

Nee joh... En als dat wel zo is, dan ook in applicaties...

Wat voegt dit toe in dit standaardprofiel?

klopt niet (context begrippenkader)

Een prov:qualifiedAttribution is toch niet een bronhouder?

Lijkt me niet te kloppen: dat zou ook voor dct:hasPart of skos:narrowerPartitive kunnen gelden.

Wat is dit? Lijkt ook niet te kloppen: taalbindingen moeten 2 kanten uit kunnen, dat lukt hier niet

Wat is dit?

Wat is dit?

Dit zou "Bron" moeten zijn. En we hebben niet 1 taalbinding, maar meerdere, die we wel allemaal denk ik moeten benoemen (dct:BibliographicResource, foaf:Document, etc)

In dit diagram zitten voor mijn gevoel twee zaken nog niet helemaal lekker: - Begrippenkader is zowel begrippenkader als asset, terwijl we dat in hoofdstuk 2 uit elkaar hebben getrokken - Bronverwijzing: volgens mij is dit de Bron zelf.

Voor mijn gevoel zitten hier dingen tussen die niet bij de semantische asset horen, maar bij begrippenkader of begrip. Is het niet handiger om te stellen dat elke semantische asset een dataset is zoals in DCAT?

Dit is raar: nu maken we van een begrippenkader opeens OOK een semantische asset, terwijl we daarvoor juist zeggen dat een begrippenkader dat NIET is. Lijkt me waardevoller om te stellen dat er zoiets is als een "beschrijving van...", en dat je dergelijke beschrijvingen semantische assets kunt noemen. En dat je verschillende beschrijvingen bij elkaar kunt nemen (maar dat het niet per sé altijd alle begrippen-van-1-begrippenkader hoeft te zijn). Wellicht dat we kunnen mappen op PROV-O? We noemen dit dan een "Semantische asset" bv?

Dit zou ik eerder bij begrippenkader verwachten

Het is mij conceptueel nog niet helemaal duidelijk hoe het werkt: is "Bron" nu een afzonderlijk iets (en bronverwijzing dan een eigenschap van "Begrip"), of...

Waarom dit zo bij collectie? Bij begrippenkader is dit anders gedaan.

Dit klopt niet helemaal. Het is niet zozeer dat een collectie kleiner is t.o.v. een begrippenkader. Wat wel zo is, is dat een begrippenkader een context geeft. Dus een begrip behoort tot een begrippenkader als het "binnen" die context valt. Bij een collectie is het juist net andersom: een collectie bestaat uit begrippen. Dus of een begrip bij een collectie hoort, wordt niet bepaald door de betekenis van het begrip zelf, maar door wat de collectie-eigenaar vindt dat in "zijn" collectie hoort. Anders gezegd: een begrippenkader is een "open" verzameling: de verzameling bestaat uit de begrippen die bij dit begrippenkader horen (obv de context), een collectie is een "gesloten" verzameling: de verzameling bestaat uit de begrippen die als lid zijn toegevoegd aan de verzameling.

Ik zou deze sectie veranderen in een overzicht van mogelijke uitbreidingen, maar de uitbreidingen hier niet inhoudelijk behandelen.

Zie ook vorige: dit klopt niet met de bron

Dit klopt niet: broadMatch stelt niet of iets specifieker is of alleen maar breder. Je mag hier bv ook stellen dat je het begrip "fietsbel" relateert aan "fiets" in een ander begrippenkader, maar een fietsbel is niet specifieker dan fiets...

Het is me op basis van deze definities niet helder wat het verschil is tussen "semantische relatie" en "is gerelateerd aan". De woorden geven eerder verwarring... Nu weet ik het wel vanuit SKOS, maar we willen hier juist nog los van SKOS kijken. Is het dan wel nodig om "semantische relatie" op te nemen? Dat kan toch ook gewoon in de taalbinding expliciet worden gemaakt?

Ik zou deze hier niet neerzetten. Hoewel het vanuit de opbouw van de terminologie wel klopt, past deze hier niet, maar juist pas bij de thesaurus.

Dit begrip introduceren we nog niet. Transitiviteit is lastig om uit te leggen: is dat wel handig om (nu al) te doen?

Maar die heb je hierboven bij taxonomie ook al gegeven. Feitelijk moet "semantische relatie" niet bij de taxonomie, maar bij de thesaurus. Daarnaast kun je in een thesaurus ook de hiërarchische relatie nog specifieker maken (zoals we hieronder ook doen, dat zou ik hier dan ook bij definiëren)

Dit weghalen?

Dit klopt niet. Dat geldt alleen voor specialisaties van dit begrip. Ik zou hier spreken van "onderliggend. begrip in de hiërarchie" (en dit ook gelijk als de voorkeursterm gebruiken, zie ook vorige opmerking)

Waarom dan de term "bovenliggend" niet ook gebruiken in de voorkeursterm? Ik zou liever spreken van "heeft bovenliggend begrip" en dan als alternatieve term "heeft breder begrip". De term "breder" is voor taalkundigen goed uitlegbaar, maar voor de gemiddelde lezer niet, terwijl bovenliggend voor iedereen wel helder is.

Een definitie moet specifiek zijn, "met name" is niet specifiek.

In skos is skos:example een specialisatie van skos:note. Daarmee zou skos:example dus een notitie worden en geen voordeel van het gebruik van een begrip. Klopt deze definitie nog wel goed?

Het is denk ik goed om onderscheid te maken in verschillende verwoordingen van de betekenis, zoals: - definitie (oftewel de "formele definitie"; - uitleg (oftewel de "informele definitie"; - brondefinitie (oftewel: de definitie zoals letterlijk in de bron) We kunnen daar dan ook expliciete eisen en eigenschappen aan hangen, zoals: uitleg is in klare taal (en heb je er maar eentje van), brondefinitie is zoals letterlijk in de originele bron (daar kun je er dus meer van hebben); (formele) definitie heb je er ook maar eentje van, en deze voldoet aan formele regels.

Ik zou zeggen "verwoording van de betekenis"

De voorkeursterm is dan ook (mogelijk) een code? Wellicht hierbij nog vermelden dat codes niet per sé leesbaar hoeven te zijn? Ik zou overigens "code" niet onder notities (notes) willen laten vallen, maar onder notaties (notation), waarbij feitelijk een term een speciaal soort notatie is

Waarom "opmerking" en niet (gewoon) "notitie")?

Engels

"historische notitie" betekent in normaal Nederlands een notitie die historisch is ("historische" is hier een bijvoeglijk naamwoord van het zelfstandige naamwoord "notitie"), we bedoelen echter een notitie over de historie (van een begripsbeschrijving). Ik zou dan ook liever spreken van een "historie-notitie"

Ik zou notities graag willen splitsen: (a) de verwoordingen van de betekenis en (b) aanvullende notities. Onder (a) vallen de definitie, toelichting en uitleg (in klare taal), onder (b) vallen de redactionele notitie, de wijzigingsnotitie, de historie notitie

Ik zou begrippenlijst graag willen verbinden aan begrippenkader, dus "een begrippenlijst is een begrippenkader dat..."

Niet de bron van de definitie, maar de bron van de betekenis. Er ontbreekt vaak een bron waar de definitie letterlijk in voorkomt, en vaak is het zelfs zo dat de bron een net iets andere verwoording gebruikt. We willen die vrijheid houden.

Mogelijk woord. Ik zou zeggen: "Een toelichting op de definitie is aanbevolen"

Dit lijkt me te smal. Een notitie hoeft geen verwoording van de betekenis te zijn, dus ik zou liever willen spreken over een verwoording van de betekenis, bij voorkeur een definitie (maar het mag ook een uitleg zijn?)

Waarom? Volgens mij wil je iets weten over de betekenis. "conceptualisatie" is in deze een wat moeilijk woord, dat zou ik vermijden.

Stadium waarvan? Volgens mij stellen we dat een begrippenkader dat slechts een lijstje is van begrippen (en dus geen relaties tussen begrippen kent), we classificeren als "begrippenlijst".

Dit hoort hier niet, dit staat al bij de use-cases. Het klopt dan ook niet, want we hebben verschillende toepassingen.

"begrip" is net wat meer dan de tekening hieronder. Want een "begrip" is niet zomaar iets in het hoofd van een persoon, het is geen we samen (in een zekere context) begrijpen als hetzelfde, dus van de dingen-in-ons-hoofd geldt dat het begrip het deel is van die gedachte waar we hetzelfde over denken (letterlijk ;-)). Dit zou er bij moeten.

Hoort deze niet bij begrip ipv begrippenkader?

Dit is dan toch generiek voor alles? En niet alleen voor een begrippenkader? Zouden we niet deze termen afzonderlijk moeten definiëren?

Conceptueel zouden we het begrip "context" nog wel moeten uitleggen.

Wellicht hierbij vermelden als je (dus) geen hiërarchie hebt, een topbegrip niet nodig is (dwz: use case 1)

Wellicht ter verduidelijking toevoegen dat we daarmee WEL de betekenis overnemen van SKOS en ISO25964, maar dat we daarmee niet suggereren dat een RDF serialisatie de enige mogelijk serialisatie is. De betekenis is (dus) echter wel hetzelfde als in deze standaarden.

Conceptueel is het mij onduidelijk wat nu een begrip is. Conceptueel moet echt begrip en begripsbeschrijving uit elkaar getrokken worden, want dit zijn echt volledig andere dingen. Dus als we een conceptueel model maken, dan helemeaal prima, maar dan moeten we het niet hebben over beschrijvingen, want daar hebben we het nog niet over gehad!

Dit hoeft niet. Als we de beschrijving in SHACL/OWL hebben, dan kunnen we de MIM-versie genereren. Wel goed om dat te doen, en dan uit te leggen dat we dat hebben gedaan door het te genereren.

Dit hoort niet bij de use case. Lijkt me handiger om een afzonderlijke sectie te maken met mogelijke uitbreidingen

Niet alleen typering van concepten, ook typering van relaties tussen concepten. Overigens: zou het niet "begrippen" moeten zijn?

Dit is invulling (de oplossing). Lijkt me niet in een use case te horen.

Ik zou dit in 1 use case uitschrijven, namelijk "typering van de hiërarchische relatie": ALS beheerder van een begrippencatalogus WIL IK onderscheid kunnen maken tussen hiërarchische relaties. Bijvoorbeeld: generalisatie/specialisatie, deel/geheel, klasse/instantie.

Dit hoort w.m.b. niet in de use case beschrijving, maar in een good practice beschrijving.

begrippen

begrippen ipv concepten? We gebruiken toch de term "begrip" als voorkeursterm?

Hoewel de tekst prima is, heb ik het idee dat dit voor veel mensen moeilijk leesbaar zal zijn. Kunnen we dit niet praktischer maken? Dat er samenhang is tussen begrippen en een ontologie (in semantische standaarden), oftewel tussen begrippen en een conceptueel informatie model. Dat vaak klassen uit dergelijke modellen verdere (formelere) invullingen zijn van een begrip en dat het belangrijk is dat de relatie tussen beide modellen goed in beeld is: voor het goed kunnen begrijpen (door mensen) van een ontologie en/of conceptueel informatiemodel, is deze standaard cruciaal.

Ik vind de tekst van de rationale nog best ingewikkeld. Zeker als het duidelijk moet maken waarom we deze standaard nodig hebben. Ik zou zelf zeggen dat het steeds belangrijk wordt dat we elkaar begrijpen, en dat daarvoor een goede beschrijving van de begrippen die we gebruiken in communicatie (rechtstreeks of via informatiesystemen) belangrijk is.

Deze tekst lijkt me meer in een leeswijzer te horen dan in de sectie over de rationale

Gaan wij niet wat verder? SKOS is daar bedoeld voor het publiceren van begripsbeschrijvingen op het web. Maar dit standaardprofiel is voor veel meer bedoeld: namelijk voor het überhaupt beschikbaar stellen van begripsbeschrijvingen. Of je dat nu doet op het web (internet) of in je eigen organisatie, op het intranet of in een specifieke applicatie. Of zelfs "gewoon". op papier...

Niet direct duidelijk waar naar wordt verwezen: de semantische standaard of de voorliggende standaard? Zie ook andere opmerking: wellicht beter om het "dit standaardprofiel" te noemen?

Semantische standaarden? Dus zoals in semantic web. Of bedoelen we standaarden voor het beschrijven van betekenis. Wellicht handiger om dat te benoemen?

Maken we een standaard of een profiel? Wellicht even kijken naar vergelijkbare "standaarden" op de pas-toe-of-leg-uit lijst. Feitelijk maken we een "standaardprofiel", dwz: een profiel dat je standaard moet gebruiken...

wordt ipv worden