Dit document bevat een vertaling van het conceptuele model van NEN2660-2 - Regels voor informatiemodellering van de gebouwde omgeving naar tabellen die gebruikt kunnen worden voor uitwisseling van contractspecificaties (contractuele eisen).
Het gaat specifiek om de UAV-GC contracten waarin eisen staan in de volgende documenten, die door elke opdrachtgever anders genoemd worden:
Vraagspecificatie Proces
Vraagspecificatie Eisen
Informatieleveringsspecificatie
Status van dit document
Deze paragraaf
beschrijft de status van dit document ten tijde van publicatie. Het is
mogelijk dat er actuelere versies van dit document bestaan. Bekijk de
lijst van BIM Loket technische standaarden op
bimloket.nl
en alle BIM Loket-publicaties via
bimloket.nl.
Dit is een consultatieversie en is nog niet vastgesteld.
Een publicatie als in consultatie
impliceert geen onderschrijven door BIM Loket.
Belanghebbenden, geïnteresseerde partijen en anderen worden
uitgenodigd dit document te reviewen en hun commentaar in te zenden
vóór 1 november 2022. Zowel inhoudelijk als
technisch commentaar als commentaar betreffende de
implementeerbaarheid is welkom.
GitHub Issues wordt gebruikt voor de discussie
van dit document. Eén issue per onderwerp vereenvoudigt de verwerking.
Reviewcommentaar mag ook achtergelaten worden als
Hypothes.is annotaties. Gebruik het publieke kanaal voor je
commentaar.
1. Inleiding
1.1 Context
Een contract is een de uitvraag of overeenkomst waarmee een asset manager zijn ontwerp-, bouw- of onderhoudswerk overeenkomt met een marktpartij. Bij het opstellen van een contract gaat grote aandacht uit naar het samenstellen van contractteksten, waarna deze teksten in pdf bestanden gepubliceerd worden. Dit leidt voor opdrachtnemers tot veel werk bij aanbestedingen, omdat de contractdocumenten allemaal moeten worden doorzocht op eisen, risico’s, uit te voeren werkzaamheden, enzovoorts. Bijvoorbeeld eisen aan het bouwwerk, eisen aan het werkproces van het project of eisen aan informatieleveringen. Als de eisen als data zouden worden aangeboden kunnen deze beter worden ingelezen in de projectbeheersingsomgevingen van opdrachtnemers. Ook zouden in meerdere projecten gebruikte eisen kunnen worden herkend en automatisch verwerkt in de planning van een project.
Juridische grondslag, bijvoorbeeld de UAV of de UAV-gc
Vraagspecificatie Eisen met eisen aan het Bouwwerk
Vraagspecificatie Proces met eisen aan het proces
Informatieleveringsspecificatie met eisen aan de informatieleveringen, soms onderdeel van Vraagspecificatie Proces
Een referentie-ontwerp, berekening of een voorgeschreven ontwerp
Bij UAV: ook resultaatsbeschrijvingen met werkzaamheden en hoeveelheden van objecten/materialen).
1.2 Doel van dit document
Dit document heeft als doel om met gebruikers een eenvoudige uitwisselmethode vast te stellen voor contractspecificaties, met tabellen (in CSV), waarmee de meest gangbare applicaties voor eisenmanagement direct uit de voeten kunnen. Voor gebruikers die al verder zijn ontwikkeld op het gebied van interoperabiliteit wordt daarnaast ook uitwisseling in linked data mogelijk gemaakt.
Desgewenst kunnen gebruikers de contractspecificaties ook in andere talen uitwisselen, zoals XML, GML, Geopackage of als onderdeel van een VISI bericht. Dat is in dit document niet verder uitgewerkt.
1.3 Scope van dit document
Het gaat specifiek om de UAV-GC contracten waarin eisen staan (functionele specificaties) in de volgende documenten, die door elke opdrachtgever anders genoemd worden:
Vraagspecificatie Proces
Vraagspecificatie Eisen
Informatieleveringsspecificatie
Daarnaast wordt een mogelijkheid geboden om de overige contractuele documenten uit te wisselen per paragraaftekst.
Het betreft hier een eerste, eenvoudige afspraak over uitwisseling van contractuele eisen, waarmee alle partijen met hun huidige applicaties uit de voeten kunnen.
Het uitwisselen van het referentieontwerp of andere digitale bouwwerkinformatie is buiten scope van deze werkafspraak.
1.4 Informatiemodel
1.4.1 Bouwblokken
Het informatiemodel voor de contractspecificaties wordt zoveel mogelijk opgesteld met bouwblokken uit andere standaarden.
De volgende linked data standaarden worden toegepast:
Het conceptuele model van NEN2660-2 - Regels voor informatiemodellering van de gebouwde omgeving. Deze NEN-norm wordt gebruikt als primaire standaard en verwijst in zichzelf ook naar andere standaarden zoals SKOS, RDF-OWL en SHACL. Concepten in de contractspecificaties die hier niet in staan, maken onder meer gebruik van:
Dublin Core (DC): een standaard voor het beschrijven van content op het internet. Doel van de Dublin Core is en was om een webdocument kernachtig, met een beperkte verzameling attributen, te beschrijven en op deze manier de metadata over zulke documenten beter uitwisselbaar te maken.
1.4.2 NEN2660-2
Figuur 1 UML Schema van een deel van de NEN2660-2 voor toepassing op uitwisseling van contractuele eisen
1.5 Toepassing
1.5.1 Machine-leesbaarheid
De formats zijn zo ingericht, dat er geen dubbele informatie in staat, die zichzelf kan tegenspreken. Vanuit de eisen wordt bijvoorbeeld alleen verwezen naar de URI van het onderwerp, niet naar de naam. Dit heeft als nadeel, dat de formats moeilijker te controleren zijn door een mens. En als voordeel, dat informatie niet dubbel wordt uitgeleverd het het risico op onderlinge tegenstrijdigheden. Een deugdelijke implementatie kan dat voorkomen; als men echter geneigd is om de formats handmatig op te stellen bestaat dit risico. Omdat in de markt voldoende en toegankelijke applicaties beschikbaar zijn voor het opstellen van eisensets, is handmatig opstellen niet nodig. Als de leesbaarheid van de formats vergroot wordt, bestaat het risico dat eindgebruikers in de verleiding komen om last-minute aanpassen in de csv te doen, met kwaliteitsverlies tot gevolg.
1.5.2 Opstellen van tabellen
De tabellen kunnen het beste worden opgesteld in een applicatie die de gebruiker ondersteunt bij toepassing van het informatiemodel en het controleren van de volledigheid van de datasset. Bij het handmatig invullen van de tabellen bestaat een grote kans op fouten: dubbel gebruik van URI's, ontbrekende verplichte onderdelen, et cetera.
In een applicatie is het volgende wenselijk:
Zorg voor een eenvoudige menselijke controle op de tabellen, bijvoorbeeld door in de applicatie extra kolommen toe te voegen die wel de naam van het onderwerp laten zien. Een (juridische) controle door een mens kan op de uitgebreidere tabel plaatsvinden, waarbij de overbodige kolommen kunnen worden verwijderd voor uitwisseling. Daarmee wordt het ook mogelijk een daadwerkelijke uitgangscontrole uit te voeren als aanbestedende partij, zonder te moeten vertrouwen op de technische implementatie, wat voor veel eindgebruikers een black-box is.
Controleer of er in de eisteksten en andere tekstvelden geen codetekens worden gebruikt, die bij uitdraai naar linked data leiden tot interpretatie als code. Onder andere het gebruik van "aanhalingstekens" leidt tot foutmeldingen bij het gebruik van het ttl-formaat.
1.5.3 Inlezen van tabellen
De ontvanger van de tabellen kan deze inlezen in de eigen applicatie. Daarbij is het raadzaam om een controle te doen op de integriteit van de tabel: ontbreken van fouten zoals dubbel gebruik van URI's, ontbrekende verplichte onderdelen, et cetera.
Een ander veelvoorkomen euvel is het gebruik van leestekens en speciale in de teksten in de tabel, die bij uitwisseling worden aangezien voor code, bijvoorbeeld de overgang naar de volgende kolom, of het ontstaan van %#@# gekke tekens in de teksten omdat de ene applicatie uitgaat van html en de andere van platte tekst. Een visuele controle en handmatige aanpassing zal bij gebruik van CSV als uitwisselformaat altijd nodig zijn.
2. Doelen
Bij sommige projecten wordt onderscheid gemaakt tussen doelen en eisen. Dit komt door de werkwijze van functioneel specificeren. Bij het functioneel specificeren begin je met het vaststellen van de doelstellingen van het systeem. Vanuit die doelstellingen bedenk je welke functies het systeem nodig heeft. Daarna werk je specifieker uit hoe je de doelen wilt bereiken en welke eisen je wilt stellen.
Als je de doelen apart wilt uitwisselen van de andere eisen, dan kun je deze in een aparte tabel zetten. De kolommen van die tabel zijn hetzelfde als bij de eisentabel.
3. Eisen
Het eisenformat wordt gebruikt om de eisen te kunnen uitwisselen als data. Bij elke kolom is aangegeven wat de vertaling/binding is naar linked data standaarden, hoe vaak deze waarde ingevuld mag worden per eis ("kardinaliteit") en een beschrijving.
De URI is de unieke identifier voor de eis binnen het project.
Bij de eisen kan verwezen worden naar een eis in een eisenbibliotheek onder EisBron. Daar staat de URI van de eis uit de bibliotheek. Deze URI verwijst naar een openbaar gepubliceerde eis in een bibliotheek, bijvoorbeeld het Provinciaal Contracten Buffet.
De eis in het project moet een andere URI hebben dan de bron. Het is niet dezelfde eis, want deze wordt toegepast in (gekopieerd naar) een andere context.
URI; Voor het opstellen van URI's heeft de NEN 2660 een URI-strategie die je moet volgen.
De EisCode is een nummer van de eis in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar de eis te verwijzen, zonder de volledige URI te hoeven benoemen.
De EisNaam wordt ook wel eens de titel van de eis genoemd, en geeft een voor mensen leesbare korte duiding van de inhoud van de eis.
De EisNaam hoeft niet uniek te zijn in het project, daarvoor heeft de eis een URI. Een unieke naam is voor de menselijke lezer vaak wel handig. Soms wordt de EisNaam in applicaties bijvoorbeeld gebruikt bij het visualiseren van de eisenboom. Unieke namen helpen in dat geval.
De EisTekst bevat de voor mensen leesbare inhoud van de eis.
Op dit moment worden eisen in een contract meestal niet voorzien van een voor een systeem leesbare eis, zoals bijvoorbeeld een minimale waarde voor een attribuut van een object. Deze "dataficeringsslag" is buiten scope van dit document, omdat dit een verder gevorderd BIM niveau vraagt en dit document juist bedoelt is als opstap naar uitwisseling van data.
In de EisTekst kan verwezen worden naar een referentiedocument, waar aanvullende eisen in staan die gelden binnen het contract. De URI van dit document wordt dan opgenomen in de kolom Referentiedocument.
In deze kolom staat de URI van het Onderwerp van het verificatieplan bij de eis. Een eis kan aan meerdere Onderwerpen gesteld worden, er komen dan meerdere regels met dezelfde eis voor in de eisentabel.
Merk op, dat verwijzing naar de URI de tabel minder makkelijk leesbaar maakt voor de mens. Indien hier ook de naam van het concept zou worden toegevoegd, creëert dit dubbelingen met de onderwerpentabel en daarom mogelijk fouten. Daarom wordt alleen de URI gebruikt.
Figuur 2 Het informatiemodel voor het verificatieplan.
3.2.8 VerificatieplanMethode
In deze kolom staat de methode waarmee de eis geverifieerd moet worden. Dit is een enumeratie. Een verificatiemethode is een eigenschap van een verificatieplan. De eigenschap heeft een enumeratie van de verschillende mogelijke methoden, dat wil zeggen dat de gebruiker een lijst kan opstellen met verificatiemethoden en een waarde uit deze lijst kan gebruiken.
Bij uitwisseling mag uitsluitend de onderstaande lijst gebruikt worden bij contractspecificaties, zonder zelf uitbreidingen te doen. Als elke opdrachtgever een eigen lijst met eistypen en aspecten gebruikt wordt het inrichten van standaard omgevingen voor de verwerking van contracteisen onnodig bemoeilijkt, waarbij bij elk project een aangepaste lijst moet worden gemaakt.
Classificatie volgens:
NEN-EN-ISO 9000:2015 Kwaliteitsmanagementsystemen - Grondbeginselen en verklarende woordenlijst
ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering
Vaststellen van de status van een systeem, een proces, een product, een dienst of een activiteit. Bijvoorbeeld zettingen, monitoring van draaiuren t.b.v. optimale vervanging
In deze kolom staat de fase van het verificatieplan. Dit is een enumeratie. Hierbij worden de volgende fasen onderscheiden:
Conceptfase
Fase om (nieuwe) behoeften van stakeholders te inventariseren en mogelijkheden te beoordelen. De eerste klanteisen en oplossingsrichting worden hier bepaald. De conceptfase kan leiden tot het initiatief voor het ontwikkelen en realiseren van een systeem.
De fase om een systeem te specificeren dat voldoet aan de klanteisen. Aan het eind van de ontwikkelfase ligt er een (startklaar) ontwerp voor het gehele systeem.
De gebruiksfase is de periode waarin het systeem wordt geëxploiteerd. Hier vinden de activiteiten plaats die nodig zijn om het systeem te gebruiken zoals beoogd.
In deze kolom staat de URI van een onderliggende eis.
Hiermee kan een hiërarchie worden aangegeven van de eisenboom zoals gebruikelijk in contracten. Een eis kan meerdere onderliggende eisen hebben, er komen dan meerdere regels met dezelfde eis voor in de eisentabel.
De URI van de gebruikte eis uit een bibliotheek (indien deze niet gewijzigd is). Deze URI verwijst naar een openbaar gepubliceerde eis in een bibliotheek, bijvoorbeeld het Provinciaal Contracten Buffet. De eis in het project moet een andere URI hebben dan de bron. Het is niet dezelfde eis, want deze wordt toegepast in (gekopieerd naar) een andere context.
De URI van een brondocument met herkomst van de eis. Deze URI verwijst naar een document in de documententabel.
Als in de eistekst wordt verwezen naar een referentiedocument, staat in deze kolom de URI van het gerefereerde document.
Instructie voor gebruik: omdat nog niet alle partijen in staat zijn om de data helemaal te verwerken, moet je het document wel in de eistekst noemen. De eistekst is leidend. Een ontvanger van de eisenset kan er ook niet van uit gaan, dat de opdrachtgever dit altijd in weet te vullen. Als in een eistekst naar een referentiedocument wordt verwezen, kan het zijn dat er geen relatie is gemaakt naar het referentiedocument.
Voorbeelden:
De eis verwijst naar een ontwerp of berekening die van toepassing is.
De eis verwijst naar een richtlijn, handleiding of norm die van toepassing is.
Deze URI verwijst naar een document in de documententabel.
In deze kolom staat het eistype. De aspecteisen zijn grotendeels overgenomen uit de Leidraad SE v3; de eistypen die aanduiden aan wat voor concept de eis is gesteld zijn aangepast aan de onderwerpen uit deze richtlijn. Dit is een enumeratie.
Bij uitwisseling mag je uitsluitend de onderstaande lijst gebruiken, zonder zelf uitbreidingen te doen. Als elke opdrachtgever een eigen lijst met eistypen en aspecten gebruikt wordt het inrichten van standaard omgevingen voor de verwerking van contracteisen onnodig bemoeilijkt, waarbij bij elk project een aangepaste lijst moet worden gemaakt.
Eistypen:
Informatie-eis
Verzameling van eisen die betrekking hebben op de te leveren informatieproducten
De beschrijving van het geheel aan samenhangende of elkaar beïvloedende eisen dat bijdraagt aan het tot standkomen en gebruiken danwel toepassen van het geintegreerde systeem.
De waarschijnlijkheid dat de activiteiten voor onderhoud kunnen worden uitgevoerd binnen de hiervoor vastgestelde tijden, onder gegeven omstandigheden teneinde de vereiste functie te kunnen (blijven) uitvoeren.
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder optredend letsel aan personen kan worden vervuld dan wel uitgevoerd en de waarschijnlijkheid dat de integriteit van de functie en de daaraan verbonden data en datastructuren gewaarborgd blijven van ongewenste beïnvloeding.
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder negatieve gezondheidsrisico's voor personen kan worden vervuld dan wel uitgevoerd.
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder ongewenste risico's voor de omgeving kunnen wordenvervuld en/of gerealiseerd.
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten binnen de hieraan gestelde eisen en PPP (People/Planet/Profit)-doelstellingen kunnen worden gerealiseerd.
De beschrijving van de gevraagde prestatie ten aanzien van het beeld en het materiaalgebruik met inachtneming van de omgevings- en de gezondheidseisen van het systeem en haar onderdelen.
De beschrijving van de gevraagde prestatie van een systeem ten aanzien van de vereiste levensduur van het systeem (als functie en als object) en haar onderdelen.
De waarschijnlijkheid dat de vereiste functie aan het einde van de levensduur op beheerste wijze kan worden teruggebracht tot minimaal secundaire grondstoffen en met inachtneming van de overige RAMSHE-aspecten.
In deze kolom staat de status van de eis. Dit is een enumeratie. Voor contractspecificaties geldt dat de status één van deze twee zaken is: actueel of vervallen.
Doel is om wijzigingen door een Nota van Inlichtingen of een contractuele wijziging in de eisenset te kunnen opnemen en met elkaar uit te wisselen.
In deze kolom staat een toelichting op de status van de eis.
Gebruikers willen de reden van vervallen toevoegen aan de eis, zodat de status onderbouwd is.
De "eigenaar" van een eis is vaak een interne rolhouder. In het contract gelden hiervoor de projectafspraken en kan de eigenaar vertegenwoordigd zijn door een andere rolhouder. Een eigenaar van een eis kan intern bijvoorbeeld de objectbeheerder zijn, maar in het contract is de technisch manager eerste aanspreekpunt voor de eis. Meestal wordt de eigenaar niet benoemd in de vraagspecificaties. Daarom is "eigenaarschap" niet opgenomen in de eisentabel.
4. Onderwerpen
De onderwerpentabel wordt gebruikt voor de onderwerpen van de eisen, bestaande uit de functies, objecttypen, werkzaamheden en informatieproducten. Op de eerste regel staan de kolomnamen. Op de tweede regel staat een korte toelichting; op de derde regel de vertaling / binding naar de NEN2660-2 en andere standaarden. Op de vierde regel staat aangegeven, hoeveel relaties er kunnen voorkomen in dit veld (multipliciteit). Als er meer dan één relatie voorkomt, komen er regels bij in de uitwisseling.
In deze kolom staat de unieke naam (URI) van het onderwerp.
In deze kolom staat de code ofwel het nummer van het onderwerp.
In deze kolom staat de naam van het onderwerp.
In deze kolom staat het type van het onderwerp: Objecttype, Functie, Werkzaamheid of Informatieproduct.
In deze kolom staat de definitie van het onderwerp.
In deze kolom staat de URI van een onderliggend onderwerp.
https://www.example.org/id/Voorbeeld-Object1
OBJ-0109
Voorbeeld onderwerp
InformationObject
Onderwerp van een eis als voorbeeld in de documentatie
https://www.example.org/id/Voorbeeld-Object2
4.2 Details onderwerpentabel
4.2.1 OnderwerpURI
De URI is de unieke identifier voor het onderwerp binnen het project ("Brug15"). Zie URI conform W3C.
Als de URI uit een ontologie ("Een brug") direct als onderwerp wordt gebruikt, suggereer je daarmee dat de projecteis altijd geldt voor dit onderwerp; dat hoeft echter niet zo te zijn. Vandaar dat hier altijd een project-URI wordt gebruikt; in een project stel je de projecteisen aan de instaties van het onderwerp waarvan het type gedefinieerd is in je ontologie ("objecttypenbibliotheek"). Gezien de eenvoud van dit uitwisselformaat, is geen verwijzing naar een ontologie opgenomen.
URI; Voor het opstellen van URI's heeft de NEN 2660-2 een URI-strategie die je moet volgen.
De OnderwerpCode is een nummer van het onderwerp in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar het onderwerp te verwijzen, zonder de volledige URI te hoeven benoemen.
De OnderwerpNaam is de voor mensen leesbare naam van het onderwerp. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.
De objecttypen en objecttypenboom ("decompositie") in het contract (Vraagspecificatie Eisendeel) zijn in NEN2660-2 een nen2660:PhysicalObject. Dit kan in de kolom Type worden ingevuld.
Functie
De functies in het contract (Vraagspecificatie Eisendeel) zijn ánders dan de werkzaamheden (Vraagspecificatie Procesdeel / ontwerp- en uitvoeringswerkzaamheden). De functies geven weer, welke diensten het "systeem" moet vervullen tijdens het gebruik; een voorbeeld is een weg, die als functie "het verkeer moet geleiden". De objecten in het contract zijn de functievervullers. De activiteiten zijn door mensen uit te voeren werkzaamheden tijdens het ontwerpen, bouwen, beheren en slopen van het object. In de NEN-2660 is een functie, bijvoorbeeld "Afwikkelen wegverkeer" ZOWEL een nen2660:Activity ALS een nen2660:FuntionalEntity.
Werkzaamheid
De werkzaamheden zijn door mensen uit te voeren activiteiten tijdens het ontwerpen, bouwen, beheren en slopen van het object. In de NEN2660 is een werkzaamheid, zoals "Opstellen Maandrapportage" een nen2660:Activity.
Informatieproduct
De informatieproducten in het contract staan vaak zowel in de Vraagspecificatie Procesdeel als in een separate Informatieleveringsspecificatie. Het betreft de gevraagde levering van 'documenten', dit kunnen alle bestandstypes zijn, ook datasets of geometrische bestanden. In de NEN2660 is een InformationObject onderscheiden. Binnen contractspecificaties wordt deze gespecialiseerd naar een cs:Document.Voorbeelden:
Informatieleveringsspecificatie:
Een rapport over het ontwerp van een weg
Een sterkteberekening van een kunstwerk
Een 3D model van een gebouw
Een linked dataset met attributen van een voetpad
Procesdeel:
Een V&G plan
Een voortgangsrapportage
4.2.5 OnderwerpDefinitie
De definitie van het onderwerp is een vrij tekstveld die het onderwerp definieert.
In deze kolom staat de URI van een onderliggend onderwerp.
Hiermee kan een hiërarchie worden aangegeven zoals een objectenboom of functieboom zoals gebruikelijk in contracten. Een concept kan uit meerdere delen bestaan, er komen dan meerdere regels voor in de Onderwerpentabel.
Net als bij de eisen, is de "eigenaar" van het onderwerp vaak een interne rolhouder. In het contract gelden hiervoor de projectafspraken en kan de eigenaar vertegenwoordigd zijn door een andere rolhouder. Een eigenaar kan intern bijvoorbeeld de objectbeheerder zijn, maar in het contract is de technisch manager eerste aanspreekpunt voor het object. Meestal wordt de eigenaar niet benoemd in de vraagspecificaties. Daarom is "eigenaarschap" niet opgenomen in de onderwerpentabel.
5. Documenten
Het documentenformat wordt gebruikt voor de definitie van de documenten. De volgende documenten worden opgenomen in de documententabel:
Brondocumenten voor eisen: dit kan een beleidsstuk zijn, of een norm of wet of ander document waarin eisen beschreven staan. Dit document wordt toegevoegd om een relatie te behouden met het brondocument en om de context van de eis te kunnen opzoeken. De eisen in de eisentabel zijn de eisen die contractueel gelden, een opdrachtnemer hoeft het brondocument niet zelf te scannen op eisen.
Van toepassing zijnde documenten, waarnaar verwezen wordt in een eistekst. Dit kan een beleidsstuk zijn, of een norm of wet of ander document waarin eisen beschreven staan. Een opdrachtnemer wordt door deze verwijzing verplicht om zelf de eisen in dit document te scannen en mee te nemen in de verificatie en validatie.
Overige contractuele documenten, zodat ook teksten in paragraven kunnen worden toegevoegd als data. Dit betreft een document, waarvan hele paragraven niet zijn vertaald naar eisen, maar een context bieden voor de eisen, bijvoorbeeld inleidende hoofdstukken van de Vraagspecificatie Eisen, Proces en informatieleveringsspecificatie. Dank zij de documententabel kan een opdrachtnemer wel de teksten per paragraaf inlezen en deze als context oproepen in eigen projectbeheersingssystemen.
De vertaling / binding van documenten is naar cs:Document als specialisatie van nen2660:InformatieObject. Merk op: ook een eis wordt gezien als InformatieObject; maar deze wordt opgenomen in de Eisentabel. In de onderwerpentabel zijn te leveren documenten/datasets (informatieleveringen) óók InformatieObject. De informatieleveringen die gevráágd worden in het contract, staan niet in de Documententabel.
5.1 Documentenformat
Het format wordt in 2 delen getoond in verband met de leesbaarheid van dit document. De laatste rij bevat een voorbeeld uitwerking.
De DocumentCode is een nummer van het onderwerp in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar hetdocument te verwijzen, zonder de volledige URI te hoeven benoemen.
De DocumentNaam is de voor mensen leesbare naam van het document. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.
In deze kolom staat de documentsectie. Deze kan gebruikt worden om een document verder op te delen. Middels de 'heeft deel' relatie kunnen net zoveel secties aan een document toegevoegd worden als er nodig zijn.
De DocumentSectieNaam is de voor mensen leesbare naam van het onderwerp. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.
Naast onderdelen die als niet normatief gemarkeerd zijn,
zijn ook alle diagrammen, voorbeelden, en noten in dit document niet
normatief. Verder is alles in dit document normatief.
NEN-2660: Regels voor informatiemodellering van de gebouwde omgeving.
W3C: World Wide Web Consortium, internationale organisatie voor de standaardisatie van het het web.
OTL: Object Type Library (en) of Objecttypenbibliotheek (nl). Term die in de bouwsector gebruikt wordt en een specialisatie is van een Ontologie.
Unique Name Assumption (UNA): de aanname dat een ding maar één naam (id) heeft en dat verschillende namen dus verwijzen naar verschillende dingen in de werkelijkheid.
OWL: Web Ontology Language [owl2-overview], bevat uitgebreidere mogelijkheden dan RDFS om een Linked Data ontologie uit te drukken.
SHACL: Shapes Constraints Language [shacl], een taal om RDF data te valideren tegen een set regels.
Ontologie: Een kennismodel van een specifiek kennisdomein in de werkelijkheid. Bevat een set regels, die gebruikt kunnen worden om extra kennis af te leiden uit gelinkte data. Met behulp van zo'n model kunnen computers begrijpen wat de data betekent en redeneren over data.
Contract: de uitvraag of overeenkomst waarmee een asset manager zijn ontwerp-, bouw- of onderhoudswerk overeenkomt met een marktpartij.
