Div. issues

[mickbaggen]

1. Leidraad SE v2, op diverse plaatsen als bron aangehaald, is niet meer van kracht. Maak dit duidelijk in de lijst met gerefereerde documenten.
2. In de lijst met gerefereerde documenten ontbreken Leidraad SE v2, Leidraad SE v3, ISO 9001, NEN 2660-2 etc. Voeg deze toe.
3. Links naar div. informatie-items in dit document zijn (nog) niet resolvable, zoals https://data.crow.nl/contractspecificaties/def/hasAsSubject. Los dit of, of verwijder de links.
4. Maak voorafgaande aan par 3 duidelijk dat deze specificatie drie tabellen gaat beschrijven: eisen (par. 3), onderwerpen (par. 4) en documenten (par. 5). Maak in een plaatje ook duidelijk in welke kolommen een link ("foreign key") is opgenomen naar een andere tabel.
5. Voeg een vierde tabel toe voor verificatieplannen. Er wordt nu gesuggereerd dat er slechts 1 verificatieplan is per project. Dit lijkt me niet redelijk: ga ervan uit dat er meerdere plannen zijn die samen de complete scope afdekken.
6. Ook bij documentsectie (5.2.8 - 5.2.10) kun je evt. een aparte tabel aanmaken.
7. De gekozen format in par. 3, 4 en 5 wil graag een regel in een Excelsheet weerspiegelen. Maar voor de leesbaarheid is dit een tamelijk lastige keuze. Voorstel: zet de verschillende kolommen gewoon onder elkaar.
8. In par. 3.2.9 wordt gezegd dat "VerificatieplanFase" de fase van het verificatieplan is. Dit is niet correct: het gaat om de levenscyclus fase van het systeem, waarvoor in dit project (een of meerdere) verificatieplan(nen) worden opgesteld.
9. Voeg bij par. 3.2.9 een aparte fase toe voor "Vervanging en Renovatie". Bij RWS is dit de komende jaren de meest voorkomende levenscylus fase.
10. In par. 4.1 (Onderwerpenformat) staan "In deze kolom staat het type van het onderwerp: Objecttype, Functie, Werkzaamheid of Informatieproduct.". Een Eis kan betrekking hebben op een Object (Galecopperbrug i.p.v. Brug), maar ook op een Objecttype (brug, of alle bruggen in dit project); op een Functie (keren water Nederrijn bij Driel), of juist op een Functietype (Keren water in een rivier op een locatie) enz. Algemeen: eisen kunnen zowel betrekking op Type als op Individueel-niveau.
11. In par. 4.2 staat dat er is gekozen om alleen project-URI's te gebruiken, en geen bibliotheek/ontology-URI's: Ik zou het echter niet onmogelijk maken om dit te doen.
12. Hoe ga je zonder bibliotheek ervoor zorgen dat het onderwerp bij 4.1 niet een ratjetoe aan URI's gaat opleveren?
13. In par. 4.2.4 staat iets over functie. In NEN 2660-1, par. 8.5.3, opmerking 2 wordt functie gedefinieerd als "De functie van een object is de activiteit die het (object) uitvoert of kan uitvoeren, zodanig dat de output van die activiteit bijdraagt aan het doel dat de betrokken stakeholder wil bereiken.". Ook mensen kunnen functies uitvoeren, zoals "De door mensen uit te voeren werkzaamheden tijdens het ontwerpen, bouwen, beheren en slopen van het object". Dit levert namelijk geld op voor de aannemer. Het gaat er dus puur om of een belanghebbende het uitvoeren van de activiteit ziet als kosten (werkzaamheden) of opbrengsten (functie).
14. In par. 4.2 kan wel een (hierarchische) hasPart relatie tussen "onderwerpen" worden aangebracht, maar niet een (niet-hierarchische) "associatierelatie". Hiermee kan je de raakvlakken tussen "onderwerpen" modelleren, een veelvoorkomend informatie-element in een SE model. En aan raakvlakken kun je ook eisen stellen.

[ElisabethKloren]

1. Leidraad SE v2, op diverse plaatsen als bron aangehaald, is niet meer van kracht. Maak dit duidelijk in de lijst met gerefereerde documenten. - verwerkt

[ElisabethKloren]

2. In de lijst met gerefereerde documenten ontbreken Leidraad SE v2, Leidraad SE v3, ISO 9001, NEN 2660-2 etc. Voeg deze toe. - verwerkt met localBiblio

[ElisabethKloren]

3. Links naar div. informatie-items in dit document zijn (nog) niet resolvable, zoals https://data.crow.nl/contractspecificaties/def/hasAsSubject. Los dit of, of verwijder de links.

Issue aangemaakt #49 > Deze kunnen pas resolvable worden als het model gereed is. Want dan wordt de ontologie geplaatst op het SPARQL-endpoint. In de tussentijd zijn dit dus wel de ID's.

[ElisabethKloren]

4. Maak voorafgaande aan par 3 duidelijk dat deze specificatie drie tabellen gaat beschrijven: eisen (par. 3), onderwerpen (par. 4) en documenten (par. 5). Maak in een plaatje ook duidelijk in welke kolommen een link ("foreign key") is opgenomen naar een andere tabel.

Uitgevoerd

[ElisabethKloren]

5. Voeg een vierde tabel toe voor verificatieplannen. Er wordt nu gesuggereerd dat er slechts 1 verificatieplan is per project. Dit lijkt me niet redelijk: ga ervan uit dat er meerdere plannen zijn die samen de complete scope afdekken.
6. Ook bij documentsectie (5.2.8 - 5.2.10) kun je evt. een aparte tabel aanmaken.

Verificatieplan is in dit geval per eis en per fase, naam wordt gewijzigd om verwarring te voorkomen.

6. Waarom? Dan moet elk document een eigen tabel krijgen; daar kan de gebruiker zelf voor keizen. Dit tekstueel toegevoegd

[ElisabethKloren]

7. De gekozen format in par. 3, 4 en 5 wil graag een regel in een Excelsheet weerspiegelen. Maar voor de leesbaarheid is dit een tamelijk lastige keuze. Voorstel: zet de verschillende kolommen gewoon onder elkaar.

Akkoord, wijzig ik

[ElisabethKloren]

8. In par. 3.2.9 wordt gezegd dat "VerificatieplanFase" de fase van het verificatieplan is. Dit is niet correct: het gaat om de levenscyclus fase van het systeem, waarvoor in dit project (een of meerdere) verificatieplan(nen) worden opgesteld.

Er is sprake van een definitiekwestie, het gaan om een Eisverificatieplan; dit plan wordt uitgevoerd in een specifieke fase. Toelichting bijgevoegd in de tekst

[ElisabethKloren]

9. Voeg bij par. 3.2.9 een aparte fase toe voor "Vervanging en Renovatie". Bij RWS is dit de komende jaren de meest voorkomende levenscylus fase.

aparte issue #53 aangemaakt, ter bespreking met de gebruikerscommissie

[ElisabethKloren]

10. In par. 4.1 (Onderwerpenformat) staan "In deze kolom staat het type van het onderwerp: Objecttype, Functie, Werkzaamheid of Informatieproduct.". Een Eis kan betrekking hebben op een Object (Galecopperbrug i.p.v. Brug), maar ook op een Objecttype (brug, of alle bruggen in dit project); op een Functie (keren water Nederrijn bij Driel), of juist op een Functietype (Keren water in een rivier op een locatie) enz. Algemeen: eisen kunnen zowel betrekking op Type als op Individueel-niveau.

Zie issue #28;

[ElisabethKloren]

11. In par. 4.2 staat dat er is gekozen om alleen project-URI's te gebruiken, en geen bibliotheek/ontology-URI's: Ik zou het echter niet onmogelijk maken om dit te doen.

zie issue #54

@mickbaggen wat is hierbij je overweging?

[ElisabethKloren]

12. Hoe ga je zonder bibliotheek ervoor zorgen dat het onderwerp bij 4.1 niet een ratjetoe aan URI's gaat opleveren?

Daarvoor verwijzen we naar de NEN: Voor het opstellen van URI's heeft de NEN 2660-2 een URI-strategie die je moet volgen. Ik plaats deze tekst bij alle locaties waar URI's gedefinieerd worden.

[ElisabethKloren]

13. In par. 4.2.4 staat iets over functie. In NEN 2660-1, par. 8.5.3, opmerking 2 wordt functie gedefinieerd als "De functie van een object is de activiteit die het (object) uitvoert of kan uitvoeren, zodanig dat de output van die activiteit bijdraagt aan het doel dat de betrokken stakeholder wil bereiken.". Ook mensen kunnen functies uitvoeren, zoals "De door mensen uit te voeren werkzaamheden tijdens het ontwerpen, bouwen, beheren en slopen van het object". Dit levert namelijk geld op voor de aannemer. Het gaat er dus puur om of een belanghebbende het uitvoeren van de activiteit ziet als kosten (werkzaamheden) of opbrengsten (functie).

Ik heb je commentaar verwerkt in de tekst:

Functie

In de [[NEN_2660_1_2022]], par. 8.5.3, opmerking 2 wordt functie gedefinieerd als "De functie van een object is de activiteit die het (object) uitvoert of kan uitvoeren, zodanig dat de output van die activiteit bijdraagt aan het doel dat de betrokken stakeholder wil bereiken."

In de [[NEN_2660_2_2022]] is een functie, bijvoorbeeld "Afwikkelen wegverkeer" ZOWEL een nen2660:Activity ALS een nen2660:FuntionalEntity.

Ook mensen kunnen volgens de gegeven definitie in de [[NEN_2660_1_2022]] functies uitvoeren, zoals "De door mensen uit te voeren werkzaamheden tijdens het ontwerpen, bouwen, beheren en slopen van het object". In dit uitwisselformaat en in hedendaagse Vraagspecificaties (Eisendeel) worden functies specifiek alleen meegegeven om aan te duiden, 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 werkzaamheden van mensen tijdens het project, waaronder die beschreven worden in Vraagspecificatie Procesdeel en de ontwerp- en uitvoeringswerkzaamheden, worden in dit uitwisselformaat niet beschreven als functies.

[ElisabethKloren]

14. In par. 4.2 kan wel een (hierarchische) hasPart relatie tussen "onderwerpen" worden aangebracht, maar niet een (niet-hierarchische) "associatierelatie". Hiermee kan je de raakvlakken tussen "onderwerpen" modelleren, een veelvoorkomend informatie-element in een SE model. En aan raakvlakken kun je ook eisen stellen.

Zie issue #55