Er is gekozen om het begrip "begrip" te definiëren in plaats van het begrip "concept". Daarmee is bewust afgeweken van de SKOS definitie, maar de reden daarvoor is niet expliciet gemaakt. Daarnaast is ook maar de vraag of het begrip "begrip" zomaar als een vervanging kan worden gezien van het begrip "concept". Het lijkt er voorl een "armere" versie van. Het originele SKOS begrip lijkt ook beter te passen op terminologie zoals gebruikt in de business rules community, zoals in SBVR en RuleSpeak. Ronald Ross heeft het bijvoorbeeld vooral over een "concept model", waarin "concepten" de first class citizens zijn. De term "concept" klinkt ook rijker dan het voorgestelde "begrip". Ze zijn echter vooral "units of thought" en passen daarmee beter bij de SKOS definitie van "concept" dan bij OWL class (of "klasse" zoals gedefinieerd in het profiel).

Zie voor het begrip concept model: http://www.brcommunity.com/articles.php?id=b779 en https://www.brcommunity.com/articles.php?id=b977 en https://www.brcommunity.com/articles.php?id=b956 .

https://www.geonovum.nl/geo-standaarden/metamodel-informatiemodellering/nationaal-metamodel-voor-informatiemodellering%5D

is broken in chapter 8

Bij de politie zijn we nu ook bezig met deze integratieslag (met deels dezelfde mensen), maar ik zie niet hoe we die twee trajecten goed bij elkaar kunnen krijgen.

Het profiel lijkt niet aan te sluiten bij het Metamodel voor Informatie Modellen zoals gedefinieerd door KING, Kadaster en Geonovum. De terminologie wijkt af (bijv. "klasse" in plaats van "objecttype"). Niet alle concepten worden beschreven in het profiel (bijv. "constraint", zie ook issue #34).

Het is niet duidelijk of het profiel moet worden gelezen als een samenhangende selectie uit bestaande modellen / vocabulaires of een nieuw model. Door andere woorden te kiezen en een uitleg te geven naast de bestaande definities lijkt het een nieuw model. Dit nieuwe model zou los van de bestaande modellen worden worden gedefinieerd; het is een apart conceptueel model. In dat model is er dan ook geen behoefte aan de eigenschap "uitleg"; dat is immers gewoon de definitie van het nieuwe model.

Voor een goed begrip van linked data en wat er (misschien wel of niet) mee kan helpt visualisatie. Bij de recente bijeenkomst bij Waternet kwam o.a. de sheet: "De profielen - Kern" aan de orde. Daarop waren verschillende (ontologische) datamodellen/taalcomponenten geplot in hun samenhang.

(onderdelen):

• Skos (fbr, skos-lex) voor begrippen (en specialisaties daarvan)
• DCAT en soortgelijken over datasets
• Shacl over structuurcontrole
• Prov over de herkomst.

Het zou m.i. erg helpen als het vormgeven van dergelijke onderdelen stap voor stap verluchtigd werden aan de hand van een voorbeeld... waarbij een youtube filmpje de voorkeur heeft. Wellicht is deze open RDF dataset een mogelijk aanknopingspunt: https://data.overheid.nl/OpenDataSets/lido/lidonovember.7z maar elke open rdf dataset voldoet waarschijnlijk. Uit het filmpje zou moeten blijken hoe je de diverse onderdelen vorm geeft / invult. Hoe je de samenhang beschrijft en hoe je de beschreven structuren raadpleegt (sparql-ed).

Bij:
2.1.2 Relaties
staat: bij Uitleg
Een concepten schema kan concepten bevatten die die het meest generiek zijn in een hiërarchie van specialisaties/generalisaties.

"die die" is dubbel. Zou moeten zijn:

Een concepten schema kan concepten bevatten die het meest generiek zijn in een hiërarchie van specialisaties/generalisaties.

Ik ben nog een beetje aan het stoeien met het plaatje http://bp4mc2.org/20181107/#drie-werkelijkheden, toch een tamelijk centraal inzicht in BP4mc2:

Essentieel is het onderscheid tussen de natuurlijke werkelijkheid (die we nooit helemaal kunnen vatten, hooguit in het getal 42), de institutionele werkelijkheid, waarin we vanuit een bepaald domein de werkelijkheid vatten in woorden en de administratieve werkelijkheid waarin we voor datazelfde domein de werkelijkheid vatten in data.

[MB] In dit plaatje hebben we getracht om de semiotic triangle te vertalen naar de drie werkelijkheden. In de natuurlijke werkelijkheid hebben we daarbij het originele plaatje aangehouden van de semiotic triangle, met daarbij (dus) de vaststelling dat als je gaat communiceren over de werkelijkheid (het “ding”) het altijd de gedachte is van 1 individu, namelijk: de spreker”. In de institutionele werkelijkheid vertaalt dit zich naar “instituut” (als de spreker, met een bedoeling ipv een gedachte, en hebben we wet neergezet, maar beter was wellicht wet- en regelgeving). In de administratieve werkelijkheid is dit dan weer het systeem, als “spreker”). Vervolgens hebben we gesteld dat er binnen elke wereld drie elementen zijn die de basis zijn voor alles: actoren/subjecten/systemen (die iets doen in een werkelijkheid), gebeurtenissen (dat wat er gebeurt) en dingen/feiten/triples (dat waarmee het gebeurt). Je kunt twijfelen over de namen, maar de betekenis zou wel duidelijk moeten zijn in elk vakje, dus:

• Wie is de spreker? (actor, instituut, linked data systeem);
• Met welke basis elementen uit hij/zij zich? (term, term, uri);
• Waarover praat ie? (ding, wet, data);
• Met welke notie? (gedachte, bedoeling, model);
• Wie handelt in deze werkelijkheid? (actor, instituut, linked data systeem);
• Wat gebeurt er? (levens, institutionele of administratieve gebeurtenis);
• Waarmee gebeurt het? (ding, feit, data)

In alle 3 views heb je volgens mij de maken met dingen/onderwerpen/klassen en gebeurtenissen.
[MB] Dat is de vraag. In ieder geval wil je in twee van de drie werkelijkheden de bedoeling en het model beschrijven. Of je de gedachte ook wilt beschrijven, is nog de vraag.

In onze beschrijving van de institutionele werkelijkheid hebben we dat opgelost door aan te sluiten bij SKOS voor de beschrijving van soorten dingen en SKOS-LEX voor de beschrijving van (institutionele) gebeurtenissen.
[MB] Eens. De “bedoeling” van het instituut in de institutionele werkelijkheid beschrijven we met SKOS en SKOS-LEX.
• In de bovenste blauwe driehoek zie ik onthologieën als beschrijving van de natuurlijke werkelijkheid.
[MB] Niet eens. De bovenste blauwe driehoek gaat over de natuurlijke werkelijkheid zoals ervaren door 1 actor. Dus ook zijn gedachten. Die hoef je niet te beschrijven voor mijn gevoel. Hooguit kun je het nog hebben over een tweede institutionele beschrijving: de maatschappelijke beschrijving, dwz: toeleidingsbegrippen.

Dit zijn universele beschrijvingen (met termen) voor dingen. Dit is wat mij betreft al tamelijk discutabel.
[MB] Eens dat dit discutabel is.

Ik ben opgegroeid met het idee van intersubjectiviteit en dat het enige antwoord op de ultime vraag over het leven, het universum en alles ‘42’ is.
[MB] Wordt de hitchhikers guide to the galaxy gebruikt als opleidingsmaterieel bij psychologie? 😉
Maar los daarvan gaat het niet alleen om dingen, maar ook om ‘het gedrag’ (de dynamiek, de factor tijd) van die dingen. Daar kunnen ontologieën niets mee.
[MB] Niet helemaal waar. Je kunt prima een ontologie maken die gedrag beschrijft, dwz: ALS dit gebeurt, DAN moet ook dat gebeuren. Probleem is alleen dat als je er geen tijd aan toevoegd, dan is het een schakeling die OF eindeloos doorratelt, OF stilstaat. Bij de IND hebben we het gedrag beschreven als ontologie, en toen moesten we zorgen dat aanleiding en resultaat niet als hetzelfde ding werden gezien in de ontologie, want dan zou ie doorratelen. Door ze uit elkaar te halen, en tijd te gebruiken om te zeggen: “en nu mogen alle resultaten gebruikt worden als aanleiding voor de volgende ronde), ging het goed. Dit is overigens ook hoe productieregels werken, dus daarmee doen we niets extra’s t.o.v. productieregels.
Wel vind ik de driehoek actor-levensgebeurtenis-ding wel een goede representatie. Misschien is ‘iets’ nog wel een betere duiding dan ‘ding’ (in het Engels wordt dit wat minder spannend: some thing). In onze huidige tekst staat trouwens precies het tegenovergestelde: we beschrijven niet de natuurljike werkelijkheid, maar de werkelijkheid zoals 1 individu deze ervaart.
[MB] Ik denk dat we voor “ding” hebben gekozen om het onderscheid met “gebeurtenis” en “actor” te kunnen maken: “iets” omvat zowel gebeurtenis als actor. Het zou overigens wel gebeurtenis moeten omvatten, en wellicht ook actor, als actor de referent is van de gedachte, dus wellicht is “iets” wel beter ja. het was m.i. dus bewust om het te hebben over de gedachte van 1 individu (let op: “ding” is dus niet van 1 individu! De semiotic triangle probeert juist uit te leggen, dat 1 “ding” door meerdere sprekers altijd meerdere gedachten zijn, en de relatie tussen de uiting (term) niet rechtstreeks loopt naar het “ding”, maar altijd via de gedachte, dus: individueel.
• In het stukje rechtsonder zijn we m.i. niet helemaal consequent een ding is juridisch niet een wet, hooguit een juridische entiteit. En de driehoek subject-juridische gebeurtenis-feit zou ik eerder juridische entiteit (of onderwerp) in plaats van feit noemen. Ik zie feit meer als de juridische gebeurtenis of misschien zelfs de pendant daarvan in de natuurlijke werkelijkheid.
[MB] Zie eerdere uitleg hierboven. Het idee was denk ik dat het gaat om de bedoeling van de wet ipv de gedachte over een ding. Maar het is discutabel idd. Juridische entiteit is wellicht wel beter, maar dat vergt wel weer uitleg! Overigens zie je dat in elk plaatje het element rechtsonder terugkomt in beide onderdelen, dus “ding” en “ding” in de natuurlijke werkelijkheid, “triple” versus “data” in de administratieve werkelijkheid en “wet” versus “feit” in de institutionele werkelijkheid. Dus daar klopt idd iets niet..
• Bij linked data systeem zou ik een stapje terug willen naar ‘systeem’ of ‘registratie’ en dit niet ophangen aan linked data. Ik wil het ook op andere plekken in de tekst nog wel eens over het gebruik van de term linked data hebben. Ik denk zelf steeds meer aan ‘data delen via het web’. We praten dan over klassen, eigenschappen, relaties en constraints. Essentieel is voor mij dat dingen (‘ietsen’) die (conform het onderliggende institutionele begrippenkader voor een bepaald domein) worden gerepresenteerd in een klasse en als instantie van die klasse een identificatie in de vorm van een uri krijgen. Een systeem kent subjecten (personen en rechtspersonen), objecten en administratieve gebeurtenissen. Dit worden allemaal klassen (en bij linked data technisch gezien triples, maar het kunnen ook rijen in een tabel worden).
[MB] Ik kan me goed vinden aan het niet ophangen aan linked data. En dan kunnen we triple ook weer data noemen, en klopt het plaatje weer. Data is uitgedrukt in een model, en modellen kennen dan zaken als klassen, eigenschappen, relaties, constraints, etc. Overigens worden het dus niet klassen, maar data, dwz: instanties van klassen. Klassen zelf zitten in het model.

Ik blijf dus wat moeite houden met dit plaatje. De parallel tussen gedachte, bedoeling en model zie ik wel en tot op zekere hoogte ook wel tussen actor, instituut en systeem. Niet die tussen ding, wet en data en ook niet tussen term, term en uri. En daarmee in het middelste stuk ook niet de parallel tussen ding, feit en triple.
[MB] Eens, het kan beter.

Los van dat we de natuurlijke werkelijkheid niet echt goed formeel kunnen vatten (we kunnen er wel mooie boeken over schrijven of films over maken die we ‘goed’ of ‘minder overtuigend’ vinden),
[MB] Eens. De natuurlijke werkelijkheid laten we los, daar gaan we niets over zeggen, behalve indirect, door vastlegging van uitspraken van actoren in een administratie. Het interessante is dan wel waar het “model” aan refereert: dit zou dus een institutionele werkelijkheid moeten zijn (relatie tussen het model en de bedoeling, dwz: owl:Class naar skos:Concept), maar wellicht hebben we dan dus meer institutionele werkelijkheden nodig…
beschrijven we in het kader van de juridische werkelijkheid alleen een thesaurus. Deze is niet instantieerbaar. M.a.w. er is in BP4mc2 niet zoiets als een (concrete) institutionele gebeurtenis, hooguit een ‘soort’ institutionele gebeurtenis, waarvoor we een term met een definitie en een uitleg hebben. Net zo zijn er geen subjecten en entiteiten, alleen soorten subjecten en soorten entiteiten. Dit aspect zou ik graag nog wat nuanceren in de tekst en in de plaatjes.
[MB] Waar, maar toch niet waar. Het is waar dat we alleen de bedoeling van de juridische werkelijkheid modelleren. Dus niet de instanties! Dat hoeft ook niet, behalve waar de feiten relevant zijn, en die worden dan gewoon onderdeel van de bedoeling (dus ook gewoon een begrip). We hoeven de instititionele feiten ook niet vast te leggen, want het gaat ons niet om die feiten, maar om de bedoeling. En de vastlegging doen we in een administratie, en dan is het conform een model (wat weer isomorf moet zijn aan de bedoeling, dwz: de relatie tussen een owl:Class en een skos:Concept via dct:subject!)

De administratieve werkelijkheid is juist weer wel instantieerbaar. Daarom heb je die ook echt nodig. De juridische werkelijkheid is vooral belangrijk vanwege de duiding voor en door mensen van deze administratieve werkelijkheid en daarmee om te begrijpen hoe deze ‘iets’ in de natuurlijke werkelijkheid representeert. Een institutionele werkelijkheid zonder data waarover kan worden geredeneerd is ‘loos’.
[MB] dat heet volgens mij “bureaucratie”: zonder bureaucratie geen rechtshandhaving 😊. Teboekstellen versus registreren 😊

Een administratieve werkelijkheid zonder onderliggende juridische werkelijkheid kan op zich wel (en wordt in de praktijk ook vaak zo gebruikt), maar hoort wat mij betreft thuis in de boeken van Kafka en niet in een transparante overheid.
[MB] Eens.

Ik wil een paar user stories uitwerken om te laten zien hoe deze mechanismen werken en illustreren met de iconen die we hebben bedacht:
• Ik wil een organisatie oprichten omdat ik samen met anderen iets wil gaan ondernemen. Ik wil niet persoonlijk aansprakelijk zijn. Dit gaat om ‘serieuze’ dingen, waar de overheid regulerend optreedt. De overheid regelt dit soort dingen in wet- en regelgeving (in dit geval rond rechtspersonen in de basis in het BW). Een organisatie bestaat pas als deze is geregistreerd bij de KvK. Dan kan een organisatie (rechts)handelingen verrichten en heeft deze rechten, waarmee je bijvoorbeeld een bankrekening kunt openen en contracten kunt afsluiten, maar ook plichten zoals BTW verplichtingen en de verplichting om verantwoording af te leggen naar de samenleving in een jaarverslag. Hier zie je duidelijk de rol van een administratieve structuur waarin data over zaken in de natuurlijke werkelijkheid worden vastgelegd conform de institutionele bedoeling. Identificatie is hierbij een belangrijk onderwerp, maar ook allerlei administratieve handelingen zoals geld uitgeven en ontvangen, belasting afdragen, verantwoording afleggen, etc.
• Een tweede is de redenatie andersom. Ik wil een jachthaventje aanleggen, welke regels zijn daarvoor en waar vind ik de data die helderheid geven in de situatie. Je legt dan via een broad match de relatie tussen een perceel (met een perceelgrens) zoals bedoeld het BAL en een perceel (met een perceelgrens) zoals bedoeld in de BRK. Hiermee wil ik vooral laten zien hoe je domeinen kunt verbinden via begrippenkaders. Zonder begrippenkaders lukt dat eigenlijk nooit goed, want systemen zijn over het algemeen gesloten (hoewel de belofte van linked data anders suggereert).

[MB] Lijkt me goed om extra voorbeelden (user stories) toe te voegen. Met name om het plaatje uit te leggen hoe de samenhang wordt gezien. En ik denk ook dat het goed is om wat meer uitleg toe te voegen, zoals feitelijk al in deze mailwisseling staat!

Er ontbreekt in het profiel expliciete ondersteuning voor constraints (ook te zien als kwaliteitsregels). Wellicht is de aanname dat SHACL al een Linked Data vocabulaire is, maar als het profiel als een samenhangend model moet kunnen worden gelezen of als een nieuw model (zie ook issue #30) dan is expliciete definitie ervan noodzakelijk.

Het op data.overheid.nl toegepaste profiel is niet DCAT-NL, maar DCAT-DONL, rechtstreeks afgeleid van DCAT-EU-AP. Zie meer info hier: https://data.overheid.nl/ondersteuning/open-data/dcat

Momenteel loopt het traject Kennisplatform API's (Geonovum). In de werkgroep API Architectuur is gesproken over (kaders voor) API registers. Is het mogelijk om de API metadata voor identificatie van API's en in het profiel gegevenscatalogus vast te leggen en zo een verbinding te maken? Kunnen die werelden (metadata voor gegevenscollecties) en API's (ontsluiting en gebruik van die bronnen) verbonden worden?

Ik zie in de huidige opzet in bpm4mc2/profiles een hoofdstukindeling die nog heel erg uitgaat van de bestaande standaarden. Behalve voor het hoofdstuk over MiM. Uit alles wat er geschreven staat en uit de keuze wat niet of wel in scope is maak ik op dat het gaat om een op zodanige manier beschrijven van de betekenis en structuur van de gegevens en de uitwisseling daarvan tussen verschillende (overheids) partijen zodat aan ten eerste eenduidig en betekenisvol kan worden gecommuniceerd tussen die partijen over zaken in relatie tot hun taken en over zaken in relatie tot hun onderlinge communicatie en ten tweede dit zodanig geformaliseerd is dat dit computerondersteund kan gebeuren. Vroegah (voor Agile) begin je zo'n omvangrijke queeste met het bepalen en definiëren van 'de onderwerpen van gesprek', zeg maar de belangrijkste begrippen. en hoe die zich tot elkaar verhouden. Dat kan in de vorm van een SKOS model (met daarin de semantische relaties) waarin zaken als Begrip (Concept), Klasse (Class, Object type), Partij (Actor, Agent), Gebeurtenis, Wet (Act), AbstractArtefact (Work, Asset, Controlled Vocabulary), Artefact (Expression, ..) opgenomen zijn. Waaraan vervolgens de infologische relaties worden toegevoegd die het begrip van het totale gebied vergroten. En dan pas alle detail attributen. Dat is grotendeels een herordening van wat je nu hebt.

Het profiel biedt op dit moment geen ondersteuning voor bedrijfsregels zoals bijvoorbeeld uitgedrukt kunnen worden in SVBR of RuleSpeak. Bedrijfskennis wordt bij voorkeur op dit niveau gedefinieerd en het is jammer dat juist dit niveau ontbreekt. Daarnaast zou het ook mooi zijn als er een standaard (basis)mapping is van bedrijfsregels op Linked Data vocabulaires. De mate waarin dit soort regels worden ondersteund is nader te kiezen. Ondersteuning kan ondermeer door:

• het toevoegen van het concept "business rule" conform SVBR.
• het toevoegen van het concept "statement" conform SBVR
• het onderscheiden van verschillende soorten business rules zoals "definitional business rule" en "behavioral business rule" (conform SVBR)

Dataset wordt op dit moment beschreven op 3 niveaus:

• Dataset (algemeen): dit is een versieloze dataset die alle versies van de data beschrijft die er ooit zijn geweest of nog gaan komen. Een voorbeeld is 'de BRK'
• Dataset versie: dit beschrijven we nu als een versie die ontstaat als er een nieuw informatiemodel wordt gepubliceerd. Een voorbeeld is 'de BRK volgens IMKAD 2.1'. Issue dit is semantisch niet helemaal correct. Eigenlijk ontstaat bij iedere mutatie van de BRK een nieuwe versie. Bij een nieuwe versie van het informatiemodel gaat het het dus niet echt om een nieuwe versie van de dataset zelf, alleen om een nieuwe versie van het model van de data.
• Productmodel: dit wordt afgeleid van de dataset versie. Hier geldt dezelfde opmerking als bij de dataset versie dat dit semantisch niet helemaal correct is.

In de huidige profielen lopen de Dataset versie en de asset beschrijving daarvan 1 op 1 (staat nu foutief op 0:n). Dit geldt ook voor het dataset product en de asset beschrijving daarvan.

Het is eenvoudiger en volgens mij semantisch correcter om deze structuur te vereenvoudigen:

• De dataset blijven beschrijven als een versieloze dataset die alle versies van de data beschrijft die er ooit zijn geweest of nog gaan komen.
• Dataset type kan vervallen, net als dataset versie en dataset product.
• Een dataset wordt beschreven als asset in een asset beschrijving. Deze beschrijving gebeurt in de vorm van een informatiemodel (wdrs:describedBy). In de tijd zullen verschillende versies van deze beschrijving ontstaan. Zo'n versie is een nieuw informatiemodel.
• De relatie tussen versies kan worden weergegeven via adms:next en/of adms:previous.
• De adms:versionNotes en adms:version worden toegevoegd aan de asset. Door dit op een algemeen niveau te doen kunnen ook version notes en versie identificaties worden gebruikt voor releases van waardelijsten en begrippenmodellen (dat kan met de huidige profielen niet).
• De relatie tussen de asset met een informatieproductbeschrijving en de asset met een informatiemodelbeschrijving kan worden weergegeven met dcterms:relation.
• dcterms:LicenseDocument en dcterms:RightsStatement kunnen direct worden gekoppeld aan de asset distribution.

De distributies die nu in het dataset profiel worden beschreven kunnen dan ook vervallen:

• Als je op zoek bent naar informatie over een dataset is er de datasetbeschrijving.
• Als je op zoek bent naar een beschrijving van de informatie in een dataset op een bepaald moment ga je naar:
  ** de assetbeschrijving voor het informatiemodel (bijvoorbeeld IMKAD 2.1)
  ** de assetbeschrijvingen voor de bijbehorende waardelijsten (bijvoorbeeld de waardelijst Kadastrale gemeenten gepubliceerd op 1/9/2018)
• Als je op zoek bent naar een beschrijving van informatieproducten voor een dataset ga je naar de assetbeschrijving van het productmodel (bijvoorbeeld het Kadastraal objectbericht)
• Als je op zoek bent naar een beschrijving van een concreet product ga je naar de beschrijving van een distributie van een product (bijvoorbeeld de soap service voor het Kadastraal objectbericht).
• De beschrijving van de distributie bevat de uri van de WDSL die bij de SOAP service hoort, de Swagger file die bij de API hoort, de XSD van een XML download of het SPARQL endpoint.
• Via de WDSL, Swagger file, XSD, SPARQL of endpoint vind je de feitelijke data van die distributie.

De vocabulaire https://www.w3.org/TR/tabular-metadata is beoogd en geschikt voor het beschrijven van tabelgerichte datastructuren, zoals CSV en relationele databases. Gezien de grote hoeveelheid bestaande database op basis van deze inrichting, kan het interessant zijn om hiervoor een profiel op te nemen op BP4mc2, en daarmee de verbinding te kunnen leggen met de meer functionele datamodellen die je met het SHACL profiel kunt realiseren.

Het model biedt geen ondersteuning voor fact-based modeling. Er is geen uniforme interpretatie van wat dat precies is, maar duidelijk is dat werkwoorden ("fact types" of "verb concepts") daarin een centrale rol spelen. Een fact-based model is ook vooral een conceptueel model (of concept model in de termen van Ronald Ross, zie: https://www.brcommunity.com/articles.php?id=b977). Daarmee past het beter bij SKOS dan bij OWL (het zijn vooral "concepts", units of thought).

De basisondersteuning voor fact-based modeling is het vervangen van het begrip "begrip" door "concept" (zie ook ander issue: #31). Verdere ondersteuning voor fact-based modeling kan ondermeer door:

• het onderscheiden van "noun concept" en "verb concept" als specialisaties van "concept" (conform SBVR)
• het ondersteunen van verbalization door het toevoegen van het concept "verb concept wording" (conform SBVR) en daaraan gerelateerde concepten