14 Matching Annotations
  1. Last 7 days
    1. 2.1 Richtlijnen voor het ontwikkelen van een OTL

      Ik vind de volgorde van de paragraven onduidelijk 2.1 gaat over een OTL, 2;.2 over een woordenboek en 2.3 over een ontologie (= weer OTL). Misschien is het goed eerst de niveaus te beschrijven waarop je een OTL kan bouwen? Dus van woordenboek (thesaurus) door het toevoegen van relaties naar een ontologie? Ik mis eigenlijk een inhoudelijk inleidend hoofdstuk.

    2. semantische informatiemodellen

      Hier wordt gesproken over 'Semantische informatiemodellen', eerder over OTL'en. Je kunt het ook nog ontologieën noemen. Ik zou ergens in het begin zeggen dat dat allemaal hetzelfde is.

    3. een diversiteit van gebruik van bestandsformaten

      Volgens mij is dat problematiek die niet direct met een OTL te maken heeft, maar meer met het feit dat het na het wegvallen van COINS ontbreekt aan een uitwisselstandaard voor areaalgegevens.

  2. Dec 2022
    1. figuur 4

      Dit zou figuur 6 moeten zijn.

    2. Figuur 1 Structuur data objecten in PIM Figuur 2 Positie en detailniveau PIM-OTL

      Afbeeldingen werken niet. Geldt voor alle afbeeldingen in het document.

    3. Het Informatiemodel Beheer Openbare Ruimte (IMBOR) bevat de afspraken over de benamingen en definities van alle type objecten in de openbare ruimte en de beheergegevens die per type object vastgelegd kunnen worden. De objecttypen uit de Basisregistratie Grootschalige Topografie vormen de de geometrische representatie van de objecten in IMBOR. Zie ook deze website en deze viewer

      Dit stukje tekst komt hier heel erg uit het niets vallen. Heeft geen betrekking op Boskalis of PIM. Ik zou het weglaten of verplaatsen.

  3. Sep 2022
    1. 5.2.10 DocumentSectieTekst

      Waarom de paragraaftekst? De documententabel is toch alleen maar een overzicht de documenten die bij het contract gesloten zitten? Waarom zou de tekst uit die documenten dan overgenomen moeten worden in de documententabel?

    2. RAMSHE

      Ik zou hier 'overge aspecten' noemen. Dat de eerste serie aspecten op RAMSHE gebaseerd is is denk ik niet zo relevant, maar blijkt ook niet uit de tekst.(Nederlands/Engels).

    3. 3.2.14 EisType

      Ik mis hier een eistype waar je ontwerprandvoorwaarden in kwijt kunt. Bijvoorbeeld: 'De onderlinge afstand tussen de wildreflectoren op bermplanken dient maximaal 50 meter te bedragen.', 'Verharding met een open deklaag dient te zijn voorzien van asfaltlagen waarvan elke laag aan weerszijden minimaal 0,15m smaller is dan de daaronder gelegen laag', 'Bebording dient zo veel mogelijk gecombineerd te worden op één drager tot een maximum van drie borden.'. Wij classificeren die nu als 'Ontwerprandvoorwaarde', maar het zou fijn zijn daar een landelijk afgesproken type voor te kunnen gebruiken.

    4. 3.2.7 VerificatieplanURI

      Als verificatieplan een apart objecttype is, dan is het wat gek om hier door te gaan met nummeren. Ik zou eerst alles van de eis zelf op een rijtje zetten, dan pas Verificatieplan met zijn attributen.

    5. De eis verwijst naar een richtlijn, handleiding of norm die van toepassing is.

      Deze vormt dan de herkomst voor de eis (= 3.2.12).

    6. De URI van een brondocument met herkomst van de eis. Deze URI verwijst naar een document in de documententabel.

      Is dit niet hetzelfde als 3.2.13? Wat is het verschil tussen een brondocument en een referentiedocument?

    7. Hier staat denk ik onbedoeld twee keer hetzelfde (attributen en voorbeeld van een eis).

    8. of het ontstaan van %#@# gekke tekens in de teksten omdat de ene applicatie uitgaat van html en de andere van platte tekst.

      Helpt het om in het uitwisselformaat eisteksten en dergelijke altijd tussen quotes te zetten? Zodat de speciale tekens als tekst worden gezien?