In NEN 2660 is GeometricEntity een Representation > InformationObject > Object > Entity > ConcreteConcept. Geometrie is daar dus een concreet informatieobject. Hetzelfde geldt voor TemporalEntity (ook onder Representation, dus concreet).

In IMWO wordt geometrie (AbstracteRuimte, GeometrischeRuimte) en tijd (Tijd) juist onder AbstractConcept gehangen als wiskundige ruimte. En via imwor:bronterm "Geometrische entiteit" claimt IMWO dat dit de NEN 2660-GeometricEntity is. Dat is volgens mij niet correct

Wat in de de NEN concreet/representationeel is, wordt in IMWO abstract/wiskundig.

IMWO's keuze is begrijpelijk (en misschien zelfs beter dan NEN 2660), maar het volgt dus niet de NEN2660 en dit zit een beetje verstopt

De "Top"-collectie van IMWO is in feite een lokale hertekening van NEN 2660. Dat is meteen de kern van het probleem: IMWO kopieert NEN 2660 tekstueel in plaats van het te importeren en te mappen. Dat is wellicht voor nu nog goed, maar de implementatie kan handiger waardoor het ook makkelijker wordt om de semantische correctheid te controleren

• IMWO gebruikt skos:Collection (bijv. imwom:Bouwwerken) om concepten logisch te groeperen in modules/pakketten, zonder dat dit de hiërarchie (skos:broader) in de war schopt. Dit is een best practice.

• Identifiers: IMWO kent aan elk concept een unieke UUID toe via dct:identifier (bijv. "7bf417f7-5234-11f1-a512-00ffdb61c323"). Dit is uitstekend voor versiebeheer en persistentie, mocht de naam (prefLabel) van een concept in de toekomst veranderen

SKOS is bedoeld voor thesauri en begrippenlijsten (zachte semantiek). OWL is voor harde logica en datamodellen. IMWO probeert UML-achtige datamodel-eigenschappen (zoals cardinaliteit en associatienamen) in een SKOS-bestand te stoppen via custom properties (imwor:relatieCode "R5").

Het maakt het SKOS-bestand onnodig complex en onbruikbaar voor standaard SKOS-viewers. NEN 2660 houdt dit veel schoner door SKOS puur voor de begrippenlijst te gebruiken, en de harde relaties in aparte OWL/SHACL bestanden te definiëren.

Ook hier denk ik te weten waarom dit is, maar zeg het toch even.

IMWO leunt zwaar op NEN 2660, IFC, NEN 3610 en IMBAG. Echter, in plaats van standaard Linked Data-koppelingen te maken (zoals skos:exactMatch, skos:broadMatch of owl:equivalentClass naar de URI's van die standaarden), gebruikt IMWO platte tekst en custom properties: imwor:bronterm "TopConcept"@nl imwor:parentPackage "NEN2660"

Dit breekt het hele idee van Linked Data. Een computer kan de string "TopConcept" niet automatisch koppelen aan https://w3id.org/nen2660/term#TopConcept. Het gebruik binnen IMWO van skos:exactMatch nen2660-term:TopConcept ; zou toch wel erg handig zijn.

Ik denk te weten waarom dit is, maar zeg het toch even.

Hierin zit "platte" reïficatie van relaties

Bijvoorbeeld:

skos:related imwo:Entiteit ; imwor:relatieCode "R3" ; imwor:relatieSoort "heeft relatie met"@nl ; imwor:relatieNaam "isImplementatieVan"@nl ; imwor:gerelateerdAan imwo:Entiteit ;

skos:related imwo:Entiteit ; imwor:relatieCode "R3" ; imwor:relatieSoort "heeft relatie met"@nl ; imwor:relatieNaam "isDeelVan"@nl ; imwor:gerelateerdAan imwo:Entiteit ;

RDF is een set van losse triples. Als een parser dit inleest, krijgt het subject imwo:Entiteit simpelweg twee keer de eigenschap skos:related, twee keer imwor:relatieNaam ("isImplementatieVan" en "isDeelVan"), enzovoort. De relatie tussen de specifieke naam en het specifieke doelobject gaat volledig verloren. Een machine weet niet meer of "isDeelVan" bij de eerste of de tweede skos:related hoort.

Deze redentatie ontgaat me ook even. Waarom zou dit niet gewoon nen2660:Matter zijn?

Mij is niet duidelijk waarom deze relatie zelf gedefinieerd wordt en niet isBoundBy of isConnectedTo gehanteerd wordt.

Deze komt een beetje uit de lucht vallen en wordt nergens anders gebruikt volgens mij. Wordt hier de nen2660:TechnicalEntity bedoeld? Dan moet deze nog vaker aangehaald worden volgens mij.

Zou dit niet simpeler zijn als je gewoon nen2660:TopConcept direct gebruikt?

In mijn beleving betekent dat het concept op zichzelf kan bestaan, in tegenstelling tot een eigenschap zoals 'kleur', die alleen kan bestaan aan een object

Ik snap de redenering wel. Maar ik vind toch dat als je de NEN2660 volgt je dan ook wel binnen die terminologie moet blijven. Daar komt bij dat 'Ruimte' en 'Space' zoals de NEN2660 ze hanteert ook echt ontologisch anders zijn en dus FysiekeRuimte wellicht tot verwarring kan leiden.

Dit is inderdaad een correcte bevinding en een best wel onhandig punt. Misschien kan Michel of Paul hier wat over zeggen?

Lijkt dubbel?

Typo

Deze lijken me een beetje random. Ziet hier een gedachte achter of kunnen we dit ook aanpassen?

Misschien linkje naar viewer opnemen ipv opnoemen.

Wat is het doel van deze samenvatting? Hoef ik de SBB dan niet meer te lezen en kan ik wel een goed woordenboek maken?

Of is het gewoon een samenvatting en sla vooral de SBB er op na? In dat geval is deze dan te lang.

Volgens mij heb je met name handvatten nodig: hoe pas ik de SBB toe.

Dit bestaat mijns inziens niet

Dit is behoorlijk out-dated. Deze verwijst naar IMBOR2020. De principes zijn hetzelfde, maar wellicht dat dit verwarring oplevert

Verwijzing zou hier moeten zijn naar een richtlijn

Dit stuk begrijp ik toch niet goed. Even over hebben graag.

Richtlijnen

Zie ook de terechte opmerkingen van Mick. Hier is de semantiek wel heel erg van belang.

Hiervoor is het van belang dat niet alleen de content van de OTL uniek identificeerbaar is, maar ook de OTL (versie) als dataset. De metadata dus.

Volgens mij zou je hier ook heel goed richtlijnen/best practices voor kunnen maken, e.g.: * open * respec * ...

Dit is een hot debate. Sommigen zullen zeggen dat het ook RDFS+OWL+SHACL moet (kunnen zijn)

Geen MIM?

Dit is een hele ambigue term. Vervangen en/of definiëren.

Een richtlijn moet RDF zijn. Daar zit ook het gebruik van RDF URI's in

Eventueel 5-sterren model van Tim Berners Lee aanhalen.

Nee, URI wat mij betreft

Mooie voorbeelden: * https://amsterdam.otl-viewer.com/ * https://otl.waternet.nl/ * https://otl.prorail.nl/otl/

En mijns inziens: ontologieën

typo

Volgens mij geldt vooral hier: open publicatie

Beschrijf ook de rollen van personen in het beheer van een OTL.

typo

Volgt scope niet uit een usecase?

Open gepubliceerd?

Misschien: https:/w3id.org/nen2660/

Hier gebruik je de term informatiemodellen.

De verwarring over Ontologie, Informatiemodel, OTL, Datamodel, Schema, etc. is al erg groot. Ik denk dat het goed is te definiëren wat er in deze context met deze termen bedoeld wordt en er dan consistent mee om te gaan.

Ik denk dat het van belang is te melden dat dit niet persé nodig is. Het werken met ontologiën is al heel lang gebruikelijk en ook best wel gestandaardiseert. Wat we hier proberen is binnen een vrij nauwe context meer consistentie in gebruik te krijgen zodat er meer eenheid ontstaat.

In de passage staan een aantal uitspraken waarom het wenselijk en van belang is, maar in principe zouden we dit niet hoeven doen. Het helpt alleen maar.

organisaties

Deze zou ik hier niet neerzetten. Zo kan iedereen bij alle data die men niet publiek wilde

Eigenlijk zou dit dan ook een 'automatische' viewer op basis van de LD distributie moeten zijn.

Dit moeten we dan dus nog doen :)

vastgelegd

Ik denk dat ik het daar wel mee eens ben.

Zie ook: * https://guides.visual-paradigm.com/archimate-vs-bpmn-understanding-the-key-differences/ * https://bizzdesign.com/blog/combining-archimate-3-0-with-other-standards-bpmn/

Ik gebruik voor de CROW processen ook vooralsnog ArchiMate. Omdat ik dan de interfaces met personen, producten en systemen kan vastleggen.

RASCI bevat een visualisatie methode, maar het is ook een procesmodellering methode. Ik zou deze paragraaf naar boven plaatsen en ook meenemen in de afweging.

Nice

Deze vind ik tricky hoor. Ik weet niet of dit een criteria is waar we al ons procesmodellen tegen of zouden moeten wegen.

Is een criteria ook nog: de documentatie omtrent de werkwijze? Dus of er voldoende documentatie is zodat we er makkelijk mee aan de slag kunnen en niet te veel interpretaties hoeven doen?

Nice!

Misschien 'procesmodel' al eerder definiëren?

Bijvoorbeeld: Een procesmodel is een gestructureerde weergave van een proces, activiteit of workflow binnen een organisatie, waarbij de opeenvolgende stappen, taken, beslissingen en informatiestromen worden beschreven. Het heeft tot doel om een duidelijk overzicht te bieden van hoe een bepaald proces functioneert, inclusief de interacties tussen verschillende deelnemers, systemen en middelen.

Een procesmodel kan worden weergegeven in de vorm van diagrammen, zoals stroomdiagrammen, BPMN (Business Process Model and Notation)-diagrammen of UML (Unified Modeling Language)-diagrammen. Het biedt een visuele voorstelling van het proces en helpt bij het begrijpen, analyseren, optimaliseren en communiceren van de werking van het proces.

Een procesmodel kan verschillende niveaus van detail bevatten, variërend van een hoog niveau overzicht tot een gedetailleerde specificatie van individuele taken en beslissingen. Het kan ook worden gebruikt als basis voor het identificeren van bottlenecks, inefficiënties of verbeterpunten in een proces, wat bijdraagt aan procesoptimalisatie en kwaliteitsverbetering.

Over het algemeen dient een procesmodel als een referentie- en communicatiemiddel voor belanghebbenden binnen en buiten de organisatie, waardoor een gemeenschappelijk begrip van het proces ontstaat en de mogelijkheid om het proces te analyseren en te verbeteren wordt vergroot.

of: in samenhang gebruikt moeten kunnen worden.

Dus nog niet hoe we deze zouden moeten beheren?

Wellicht dit soort zaken als 'code' opnemen? Dus met dit soort tekens omringd: `

Dit soort tabellen sorteren op alfabet?

Hier is dus 2.1 en 2.2 omgedraaid