"Artificiële" (met ¨ op de e)

Elementen uit bestaande OSLO vocabularia werden niet hergebruikt.

Voorbeelden: Adres(voorstelling), Organisatie, Identificator.

(Zie ook #41 voor Openbaar Domein)

Niet conform nieuwe situatie:

• verwijzing naar recente vocabularia op https://data.vlaanderen.be/ns is niet meer relevant;
• verwijzing naar werkgroep Datastandaarden OSLO is niet meer terecht;
• bevat nog ten onrechte link naar "publieke reviewdiscussielijst" = https://github.com/Informatievlaanderen/OSLO-Public-Discussion.

Vele klassen hebben een klassenaam en label in het meervoud. Schept verwarring --> klassenamen en labels enkelvoud maken

Alle enumeraties blijken een eigen uri te hebben.
Voorbeeld uit VOC onderdeel:
https://data.vlaanderen.be/ns/wegenenverkeer/onderdeel#BoomBoomspiegel.

Dat is niet de OSLO oplossing voor enumeraties, dewelke is:

1. Enumeraties worden ingevuld aan de hand van een codelijst.
Om in verband te kunnen gebracht worden met een codelijst, moet een enumeratie in het UML model een "uri" tag hebben gelijk aan "http://www.w3.org/2004/02/skos/core#Concept" (skos:Concept).
Let wel, eventuele in de enumeratie aangebrachte entries zijn enkel illustratief. De codelijst bevat de effectief mogelijke waarden.
Verder noemen we zo'n enumeratie een codelijst-enumeratie.

2. Elke enumeratie moet een codelijst-enumeratie zijn.

3. Om in verband te kunnen gebracht worden met een codelijst, moet een attribuut/connector in het UML model of (a) als type een codelijst-enumeratie hebben of (b) een "range" tag hebben gelijk aan "http://www.w3.org/2004/02/skos/core#Concept" (skos:Concept).
Verder noemen we zo'n attribuut/connector een codelijst-attribuut/connector.
In geval (a) noemen we de betreffende codelijst-enumeratie verder de gelinkte codelijst-enumeratie.

4. Een "ap-codelist" tag mag enkel worden aangebracht op een codelijst-enumeratie of een codelijst-attribuut/connector.
Dit wordt enkel in het applicatieprofiel gedaan.
Opgelet, elke codelijst-enumeratie moet op het diagram staan, bij voorkeur onderaan en in groene kleur, maar wordt ter vermijding van verwarring niet mee gekopieerd naar de visuele kopie van het diagram die in de specificatie wordt getoond (overview.jpg).

5. Een codelijst-attribuut/connector moet of (a) een "ap-codelist" tag hebben of (b) een gelinkte codelijst-enumeratie met aangebrachte "ap-codelist" tag hebben.
De "ap-codelist" tag uit geval (a) heeft prioriteit over die uit geval (b), die dus als default waarde geldt.

6. De corresponderende codelijst moet gepubliceerd staan op de url die ingevuld is in de "ap-codelist" tag.

Pas dus in de vocabularia de enumeraties aan tot ze "codelijst-enumeraties" zijn zoals hierboven beschreven en doe in de implementatiemodellen zoals hierboven beschreven voor applicatieprofielen.

Merk op: deze oplossing is in tegenstrijd met #3 (comment) en met #32, maar hiervoor is wel consensus met Bert en Geert.

Merk ook op dat als gevolg de enumeraties niet meer ten onrechte zullen voorkomen bij de Klassen in de VOC spec. Als nadeel kan worden opgemerkt dat hierdoor de definitie verloren gaat, maar deze hoort eveneens thuis in de codelijst zelf.

De metadata "deze versie" verwijst altijd naar data.vlaanderen.be.
Dat zou domein configureerbaar moeten zijn.

Het is geen OSLO stijl om stereotypes <<OSLO-Class>>, <<OSLO-Attribute>> en andere te laten zien in het diagram.

alle enumerations moeten een subclass zijn van http://www.w3.org/2004/02/skos/core#Concept. Dat kan je doen door de tag "subclass" te zetten.

Originally posted by @bertvannuffelen in #3 (comment)

Eigenschappen met een domeinafhankelijke uri kunnen beter in het stuk voor de . de domein uri letterlijk (inclusief hoofdletters) overnemen.
Een voorbeeld:
https://data.vlaanderen.be/ns/wegenenverkeer/abstracten#lijnvormigeelementen.aanlegdatum aanpassen naar
https://data.vlaanderen.be/ns/wegenenverkeer/abstracten#LijnvormigeElementen.aanlegdatum

Onduidelijk label; wat is V r i?

geen CamelCase in labels maar correct Nederlands
Slechte voorbeelden uit VOC onderdeel:
WindreflectorDrager
ZonnepaneelMerk
ZonnepaneelType

Dit label is allicht verkeerd, kijkende naar de uri (https://data.vlaanderen.be/ns/wegenenverkeer/abstracten#Waterlooptalud) en de definitie.

In
https://wegenenverkeer-test.data.vlaanderen.be/doc/implementatiemodel/awv-object/ontwerpdocument/niet-bepaald

ontbreekt de info over het datatype AWVIdentificator.

Voor elementen die niet op het diagram voorkomen maar opgelijst staan in de spec (bijvoorbeeld onder "Subklasse van" of in de kolom "Verwacht Type") last de toolchain een link in naar het vocabularium. Bij gebrek aan informatie gegeven aan de toolchain is dit normaal.

Echter, voor vele gevallen hier is het wenselijk om wel extra informatie te verstrekken.
Bijvoorbeeld voor alle elementen gedefinieerd in de vocabularia awv-object en implementieelement.

De oplossing om deze mee op het diagram van het plaatselijke implementatiemodel te plaatsen is niet wenselijk om het plaatselijk implementatiemodel niet te overladen.

Voorgestelde oplossing:
maak voor die vocabularia een eigen implementatiemodel en geef bij de afhankelijkheden een link naar deze implementatiemodellen (hoe: zie @bertvannuffelen ).

Concreet voorbeeld:
In IM grondwerken, bij entiteit Grond: verwacht type AWVDocument, KwantWrdInMeter

De elementen uit Openbaar Domein die exact matchen (tabel beschikbaar na meetings hierover) komen hier voor met hun eigen automatisch gegenereerde wegenenverkeer-uri, in plaats van de uri uit Openbaar Domein over te nemen.

Meermaals komt (in de .eap file) binnen eenzelfde package een enumeratie en een datatype voor met dezelfde naam.
Voorbeelden uit VOC onderdeel:
BVLaagtype
WvBevsToestellen
WvMasthoogte

De toolchain werkt hier niet voorspelbaar op.

In het vocabularium Onderdeel worden een aantal klassen gedefinieerd met in de definitie "relatie".
De meeste hebben geen attributen, twee hebben wel attributen.
Een overzicht is ook te vinden in het implementatiemodel https://wegenenverkeer.data.vlaanderen.be/doc/implementatiemodel/relaties:

De uri's:
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#BestaatUit
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#Bevestigd
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#HeeftGeometrie
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#LigtOp
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#NetwerkECC
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#NetwerkProtectie
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#SluitAanOp
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#Sturing
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#SwGehostOp
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#SwOnderdeelVan
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#TypeVan
https://wegenenverkeer.data.vlaanderen.be/ns/onderdeel#Voeding

Tegelijk komen ook gelijknamige associaties voor in het vocabularium Onderdeel, die dus dezelfde uri's krijgen als de klassen hierboven. Dit is niet OSLO-compliant: een uri kan maar voor één soort element gebruikt worden.

Deze associaties komen ook meermaals voor tussen verschillende klassen in het vocabularium onderdeel. In een OSLO vocabularium kan een associatie maar één keer gedefinieerd worden; in een implementatiemodel kan die weliswaar tussen verschillende klassen worden toegepast.

Voorstel tot verbetering.

• voor de klassen zonder attributen:

  • geef elke betreffende associatie een definitie in het vocabularium en verwijder de klasse
  • leg in het vocabularium elke associatie tussen een gemeenschappelijke basisklasse voor alle klassen waartussen deze associatie zal gelegd worden in applicatieprofielen/implementatiemodellen
  • pas in implementatiemodellen de associatie toe tussen entiteiten zoals nodig

• voor de klassen met attributen:

  • hiervoor is een associatie met bijhorende associatieklasse normaal gezien de manier van werking. Hiervoor is nog een extra oplossing nodig (toolchain? advies OSLO team?) omdat een associatieklasse horend bij een associatie tussen twee basisklassen in UML niet kan hergebruikt worden bij toepassing in implementatiemodellen tussen afgeleide klassen.

In vele definities komt "verzameling van" voor, terwijl het niet over een verzameling (container) gaat --> "verzameling" vermijden

In de uri staat "Bovenrand_onderwatertalud". Klasse hernoemen naar BovenrandOnderwatertalud (CamelCase)

In vele definities komt voor dat het een "abstracte" is; in andere dan weer niet --> formulering gelijkzetten ter voorkoming van verwarring

Bereik: zou dat niet moeten KwantitatieWaarde (of afgeleide) zijn in plaats van (rechtstreeks) Decimal?

Recursieve definitie (bevat "Laag")

Misschien kan je voor de versionering van de implementatiemodellen
de urls
{domein}/doc/implementatiemodel/awv-object/ontwerpdocument/{versie}

gebruiken.

Dan staat dat ook niet in de titel alleen.

https://data.vlaanderen.be/ns/wegenenverkeer/onderdeel#VoegType komt 2x voor in vocabularium onderdeel.

Dat leidt tot inconsistenties.

In sommige implementatiemodellen zijn er relaties die geen richting hebben en geen rollen.

De huidige toolchain maakt er momenteel dit van:
https://wegenenverkeer-test.data.vlaanderen.be/doc/implementatiemodel/riolering/ontwerpdocument/niet-bepaald/#Damwand%3ABevestigd

Er zijn zeer veel gelijkaardige eigenschappen (zie zelfde labels) in het vocabularium

https://wegenenverkeer-test.data.vlaanderen.be/doc/vocabularium/wegenenverkeer/onderdeel/ontwerpdocument/niet-bepaald/

Misschien een opportuniteit om minder eigenschappen in het vocabularium te hebben en in de context van een applicatieprofiel verder te specializeren.

Definitie niet duidelijk voor deze booleaanse eigenschap

Bereik: geen hergebruik van OSLO-Adres::Adresvoorstelling? (https://www.w3.org/ns/locn#Address)

Verwarrende naam TypenaamObject

• attributen typenaam en merknaam
• Object in de naam

In de report directory in de repository OSLO-Generated vind je rapporten over de processing.
bv.
https://github.com/Informatievlaanderen/OSLO-Generated/blob/wegenenverkeer/report/doc/vocabularium/wegenenverkeer/onderdeel/ontwerpdocument/niet-bepaald/onderdeel.report

Los best alle Errors en warnings ivm missing "definition-nl" tags op voor bv. vocabularia.

Er is geen titel bovenaan elk vocabularium.
In de tekst boven samenvatting (de inleiding) ontbreekt de naam van het vocabularium.

"van" toevoegen

Begin een definitie niet met het herhalen van de term naam, bijvoorbeeld (eigenschap boomspiegel in VOC abstracten: "De boomspiegel is het stuk grond rondom de stam van een boom, en in de ideale situatie minstens zo groot is als de kruin van de boom."

De integratie van OSLO-Generiek in de vocabularia (zie EAP file) is zeer voorlopig door zelf een package OSLO²-Generiek te maken, zonder baseURI, met partiële kopie van inhoud uit een email, waarop hardcode uri toekenningen.

Goede oplossing:

• in vocabularia: kopieer OSLO vocabularia uit versie van OSLO-Generiek op github (referentie te geven door OSLO team) en link naar de daar voorkomende elementen
• in applicatieprofielen/implementatiemodellen: geef in dependency op naar een versie van applicatieprofiel Generiek-Basis in eap-mapping.json (referentie te geven door OSLO team), aangevuld met eigen kopie van OSLO-Generiek gebruikt voor vocabularia, waaruit elementen op het eigen diagram worden gesleept en aangepast, indien afwijkende constraints gelden ten opzichte van applicatieprofiel Generiek-Basis.

Alle labels van eigenschappen beginnen met hoofdletter --> wijzigen in kleine letter

Dit veld is toch maar een informatieloze kopie van de titel er net boven:

De lijvige specs in dit thema worden er nodeloos lang door...

Label wijkt ver af van klassenaam GestandaardiseerdeKantopsluiting.
Label bevat een punt aan het einde

Er moet overal een definitie staan.
Ontbreekt bijvoorbeeld in VOC onderdeel voor:
BevestigingsbeugelType

Idem voor label.
Ontbreekt bijvoorbeeld in VOC installatie voor:
Riolering

(Aangebracht door @GeertThijs )

In de modellen wordt overerving gebruikt waar geen logisch "is een" verband bestaat van de afgeleide klasse naar de basisklasse.

Voorbeelden uit VOC abstracten:

Klassen als ArtificiëleLagen en/of AndereLagen erven over van Laagdikte, LaagProductidentificatiecode.
Maar een ArtificiëleLaag is geen Laagdikte, is evenmin een LaagProductidentificatiecode.

Oplossing: modelleren als attribuut, evt datatype van maken om attributen te groeperen.

Er komen naamloze klassen en eigenschappen voor (te zien bijvoorbeeld in het overzicht)

zie voorbeeld voor verhardingen-funderingen in https://github.com/Informatievlaanderen/OSLOthema-wegenenverkeer/blob/master/config/eap-mapping.json

Het veld "Specialisatie van" is overal leeg, alhoewel op de diagrammen in de .eap files generalisatiepijlen en/of basisklassen in rechterbovenhoek van klassen zichtbaar zijn. Voorbeeld in VOC abstract: Boomvorm is een specialisatie van AanlegBoomvorm.

De specs lijken dus een vlakke klassestructuur te beschrijven.

Waar geen specialisatie is, kan de rij met veld "Specialisatie van" misschien weggelaten worden om de spec compacter te maken.

Definitie lijkt over iets anders te gaan...

In deze klassen werd de initiële waarde van het attribuut als volgt ingegeven:

Dit is fout. Correcte manier:

(zie ook mail van @GeertThijs "opgelegde eenheden" van 21/5/2019: "Hoe je dit precies doet is beschreven in bijgaande nota")

De waarde voor Specialisatie van wordt niet getoond.

In een vocabularium onder https://data.vlaanderen.be/ns/ mag een element A niet refereren naar een element B in een vocabularium onder https://wegenenverkeer.data.vlaanderen.be/ns/.

Bijvoorbeeld voor A met uri https://data.vlaanderen.be/ns/wegenenverkeer/abstracten#put.adres is het bereik momenteel B met uri https://wegenenverkeer.data.vlaanderen.be/ns/implementatieelement#Adres.

Maak in dergelijke gevallen eerst een element Bbase onder https://data.vlaanderen.be/ns/ en laat A verwijzen naar Bbase. Leid de bestaande B nu af van Bbase. In het implementatiemodel kan dan semantisch correct nog altijd in A verwezen worden naar B.

Attributen staan systematisch private; public is de norm voor OSLO

(Aangebracht door @GeertThijs )

Op het diagram in de EAP file komen packages voor.
Wordt niet gebruikt in OSLO.
Heeft wellicht geen impact op de specs.

Label wijzigen naar enkelvoud, in lijn met klassenaam en uri

om de codelijst uri link zichtbaar te maken dan moet de tag "ap-codelist" gezet zijn.