2.4 Overzicht families
Deze lijken me een beetje random. Ziet hier een gedachte achter of kunnen we dit ook aanpassen?
45 Matching Annotations
- Last 7 days
-
docs.crow.nl docs.crow.nl
-
-
Basculebrug, Draaibrug,Dubbele basculebrug,Dubbele draaibrug,Dubbele ophaalbrug,Hefbrug,Klapbrug,Ophaalbrug, Tafelbrug, Rolbrug, Vlotbrug.
Misschien linkje naar viewer opnemen ipv opnoemen.
-
- May 2024
-
nl-digigo.github.io nl-digigo.github.io
-
Samenvatting van de Standaard voor het beschrijven van begrippen (SBB)
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.
-
IMBOR OTL
Dit bestaat mijns inziens niet
-
Link: Handleiding OTL | IMBOR-LD.
Dit is behoorlijk out-dated. Deze verwijst naar IMBOR2020. De principes zijn hetzelfde, maar wellicht dat dit verwarring oplevert
-
Versiebeheer Er wordt gebruik gemaakt van versienummering met daarbij een datum.
Verwijzing zou hier moeten zijn naar een richtlijn
-
Bij harmonisatie wordt er een mapping gemaakt tussen twee woordenboeken of tussen twee ontologieën via harmonisatierelaties. Harmonisatie is noodzakelijk om tot gegevensuitwisseling tussen deze OTLlen te komen. Wanneer de OTLlen door verschillende organisaties worden beheerd, moet de harmonisatie als een aparte OTL met een aparte beheeropgave worden opgepakt. Waarom FAIRQ Kenmerk Beschrijving I Matching through alignment Relaties tussen OTLlen (voor hergebruik en harmonisatie) zijn conform "Ontology Matching trough alignment and extension: a Best Practice" van CROW. R Interne harmonisatie Bij harmonisatie tussen OTLlen die binnen dezelfde organisatie worden beheerd, kunnen de harmonisatierelaties impliciet onderdeel zijn van een van beide OTLlen. R Externe harmonisatie Harmonisatie tussen OTLlen van verschillende organisaties moet als een aparte OTL met een aparte beheeropgave worden opgepakt. R Benoemen relaties Relaties met andere OTLlen worden (kort) benoemd in de algemene beschrijving van de OTL. R Documenteren relaties Relaties met andere OTLlen zijn uitgebreid gedocumenteerd in de technische documentatie, inclusief verwijzing naar de bron-OTLlen en de gebruikte versies.
Dit stuk begrijp ik toch niet goed. Even over hebben graag.
-
Waarom
Richtlijnen
-
2.7 Richtlijnen voor harmonisatie tussen OTLlen
Zie ook de terechte opmerkingen van Mick. Hier is de semantiek wel heel erg van belang.
-
de OTL zelf (dus het woordenboek of de ontologie)
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.
-
R Documentatie De OTL is gedocumenteerd en de documentatie is vindbaar en toegankelijk.
Volgens mij zou je hier ook heel goed richtlijnen/best practices voor kunnen maken, e.g.: * open * respec * ...
-
RDFS+OWL of RDFS+SHACL.
Dit is een hot debate. Sommigen zullen zeggen dat het ook RDFS+OWL+SHACL moet (kunnen zijn)
-
Dit zijn onder andere:
Geen MIM?
-
objecttypen
Dit is een hele ambigue term. Vervangen en/of definiëren.
-
Richtlijnen
Een richtlijn moet RDF zijn. Daar zit ook het gebruik van RDF URI's in
Eventueel 5-sterren model van Tim Berners Lee aanhalen.
-
UUID
Nee, URI wat mij betreft
-
incomplete
Mooie voorbeelden: * https://amsterdam.otl-viewer.com/ * https://otl.waternet.nl/ * https://otl.prorail.nl/otl/
-
OTLlen:
En mijns inziens: ontologieën
-
OTLlen
typo
-
Richtlijnen
Volgens mij geldt vooral hier: open publicatie
-
Beheer je OTL. Maak een planning voor nieuwe versies en houd de planning van onderliggende standaarden/OTLlen in de gaten. Organiseer ondersteuning voor gebruikers. Voor meer details hierover zie de richtlijnen voor beheer.
Beschrijf ook de rollen van personen in het beheer van een OTL.
-
OTLlen
typo
-
Kies een realistische scope die binnen de planning en het budget past. Houd de scope beperkt tot bijv. één asset of domein. Maak de scope concreet, praktisch en uitvoerbaar. Formuleer use cases.
Volgt scope niet uit een usecase?
-
Een succesvolle OTL dient het doel waarvoor hij ontwikkeld is, wordt gevonden, wordt veel toegepast en hergebruikt, beweegt mee met de wensen van de gebruikers, wordt ondersteund, en langjarig beheerd.
Open gepubliceerd?
-
de NEN-2660 serie, "Modelleringsregels voor informatie in de gebouwde omgeving";
Misschien: https:/w3id.org/nen2660/
-
informatiemodellen
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.
-
Daarom is het van belang dat Object Type Libraries (OTL) op een eenduidige manier worden opgezet zodat gegevensuitwisseling mogelijk wordt. Voor het ontwikkelen en beheren van OTL'en is het wenselijk om, met alle partijen die een OTL hebben opgezet of gaan ontwikkelen, dezelfde richtlijnen te hanteren. In de afgelopen jaren is een grote diversiteit aan OTL'en ontstaan. De diversiteit heeft te maken met het gebruik van definities, de structuur waarmee de OTL'en worden opgezet, de techniek die gebruikt wordt en de manier waarop OTL'en worden ingezet. Om meer eenheid te krijgen in de OTL'en worden richtlijnen opgezet die helpen bij het beheer en de ontwikkeling van de OTL'en.
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.
-
organisatie
organisaties
-
- Dec 2023
-
docs.crow.nl docs.crow.nl
-
URL: https://datasets.crow.nl/projecten/-/stories/Datastandaarden-in-samenhang Email address: snuffelaccountcrow@rix.33mail.com Password: Demo2023!
Deze zou ik hier niet neerzetten. Zo kan iedereen bij alle data die men niet publiek wilde
-
- Jul 2023
-
docs.crow.nl docs.crow.nl
-
Het procesmodel kan worden gebruikt om het proces visueel weer te geven. Het kan worden gebruikt in presentaties, trainingen of rapporten om een duidelijk beeld te geven van de processtappen, de volgorde van activiteiten en de interacties tussen de betrokken partijen. Dit vergemakkelijkt het begrip van het proces en kan dienen als een communicatiemiddel voor het delen van kennis over het proces. De weergave als RASCI is voor eenvoudige toepassingen de meest logische. Als een kennisproduct een gedetailleerdere weergave vraagt kunnen schema's worden opgesteld met de visualisatievormen die bij BPMN beschikbaar zijn.
Eigenlijk zou dit dan ook een 'automatische' viewer op basis van de LD distributie moeten zijn.
-
Voor BPMN is nog geen informatiemodel beschikbaar in linked data, daarom publiceren wij deze, als afgeleide van de NEN 2660-2, met zowel een begrippenkader in SKOS als een ontologie in RDF-OWL . NEN2660-2:2022:NEN2660-2 is een praktische invulling van NEN2660_1. In deel 1 zijn meer theoretische/conceptuele en bouw- en taalonafhankelijke modelleerpatronen vastgelegd. Deze norm is vrij beschikbaar bij de NEN en is ontwikkeld in een samenwerking tussen overheden, adviesbureau's en kennisinstituten. Het heeft als doel de standaard te zijn voor de ontwikkeling van ontologieën in de gebouwde omgeving.
Dit moeten we dan dus nog doen :)
-
vastgelgd
vastgelegd
-
Daarom wordt BPMN gekozen.
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/
-
4.3 Input stakeholders
Ik gebruik voor de CROW processen ook vooralsnog ArchiMate. Omdat ik dan de interfaces met personen, producten en systemen kan vastleggen.
-
3.3.4 RASCI
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.
-
Het criterium "machine-leesbaarheid" geeft aan of het procesmodel gemakkelijk door machines kan worden gelezen en verwerkt. Een machine-leesbaar procesmodel volgt vaak een standaard notatie of syntaxis die door computers en softwaretools kan worden geïnterpreteerd. Het maakt gebruik van gestandaardiseerde symbolen, tags of metadata om de elementen en relaties van het proces duidelijk te definiëren. Dit vergemakkelijkt de automatische verwerking, analyse en uitvoering van het procesmodel met behulp van softwaretools en systemen. Dit zorgt ervoor dat CROW het proces geautomatiseerd kan visualiseren voor kennisproducten.
Nice
-
Het criterium "Applicatie kan worden ingericht" geeft aan of het procesmodel voldoende informatie biedt om een applicatie te ontwerpen en te implementeren op basis van het proces. Hiermee kan het proces door softwareleveranciers worden ondersteund. Een procesmodel dat geschikt is voor het inrichten van een applicatie bevat vaak gedetailleerde informatie over de stappen, taken, gegevensvereisten, beslissingen en andere relevante elementen van het proces. Het biedt een solide basis voor het ontwerpen en implementeren van een geautomatiseerde applicatie die het proces ondersteunt, zoals een workflow management systeem of een bedrijfsapplicatie.
Deze vind ik tricky hoor. Ik weet niet of dit een criteria is waar we al ons procesmodellen tegen of zouden moeten wegen.
-
2.2 Criteria
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?
-
Bepalen met welke methode de processen vastgelegd worden; Bepalen hoe de processen als data gepubliceerd worden; Bepalen hoe de processen gevisualiseerd worden; Bepalen hoe de onderbouwing van een proces gepubliceerd wordt.
Nice!
-
procesmodel
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.
-
samenhangend geheel vormen
of: in samenhang gebruikt moeten kunnen worden.
-
Dit document beschrijft:
Dus nog niet hoe we deze zouden moeten beheren?
-
- Nov 2022
-
bakkej.github.io bakkej.github.io
-
rdfs:label
Wellicht dit soort zaken als 'code' opnemen? Dus met dit soort tekens omringd: `
-
3.2.1 Types
Dit soort tabellen sorteren op alfabet?
-
In 2.1 beschrijven we wat een begrip is. Vervolgens beschrijven we in 2.1.1 de kenmerken van ene begrip die relevant zijn voor het basisniveau, een begrippenlijst. In 2.1.2 voegen we daar de hiërarchische relaties aan toe die een begrippenlijst uitbreiden tot een taxonomie. In 2.1.3 voegen we meer genuanceerde hiërarchische relaties toe om tot een ISO compatible thesaurus te komen. In 2.1.4 beschrijven we de harmonisatierelaties waarmee begrippen kunnen worden verbonden met begrippen in een ander begrippenkader. In 2.1.5 beschrijven we skos-lex als voorbeeld van een verdergaande typering van begrippen waarmee nog meer semantiek wordt toegevoegd. In 2.2 beschrijven we wat een begrippenkader is
Hier is dus 2.1 en 2.2 omgedraaid
-