Informatievlaanderen / OSLO-Discussion

Deze repository dient als discussie forum voor de publieke werkgroepen van OSLO
6 stars 2 forks source link

overzicht van alle OSLO standaarden en hun fase in de levenscyclus is verdwenen #386

Open gezever opened 3 years ago

gezever commented 3 years ago

Model(len) waarop de issue van toepassing is: alle modellen Omschrijving van het probleem: Onder https://github.com/Informatievlaanderen/OSLO-Discussion staat er een link naar OSLO-Standaarden: bevat een overzicht van alle OSLO standaarden en hun fase in de levenscyclus. https://informatievlaanderen.github.io/OSLO Deze url geeft een 404 Omschrijving van een mogelijke oplossing:

gezever commented 3 years ago

Ik zou graag een overzicht hebben van de versionering van modellen en shapes

dimi-schepers commented 3 years ago

Een overzicht van alle standaarden en hun status vind je hier terug: https://data.vlaanderen.be/standaarden/ De nieuwste standaarden zijn ondertussen ook voorzien van metadata met versionering, zie bijvoorbeeld Mobiliteit: Trips en Aanbod.

gezever commented 3 years ago

@dimi-schepers Een overzicht in html kan nuttig zijn voor veel mensen, maar ik had onder het github overzicht een overzicht verwacht op de changes (in ttl, rdfxml, ...) van de definities van modellen en shape constraints, liefst gekoppeld aan een issue.

bertvannuffelen commented 3 years ago

@gezever wat is je verwachting hier? Want er is geen globaal overzicht in github van alle "business waardevolle" wijzingingen. En niet alles is te herleiden naar een publiek (business) issue.

gezever commented 3 years ago

@bertvannuffelen In het kader van oslo Dossier en Besluitvorming zijn er een groot aantal beslissingen genomen, die ons geïmpacteerd hebben in onze implementatie. Allereerst is ons een shacl en een rdf-model bezorgd waartegen we ontwikkeld hebben. Vervolgens is het vocabularium van dossier, waar ik dan nog als auteur wordt vermeld, opgesplitst en zijn er properties verdwenen of toegevoegd, zowel in de shacl als in het rdf-model. Het beleidsdomein Omgeving is hiervan als betrokkene slechts fragmentair en enkel op mijn aandringen van op de hoogte gesteld en er is zelfs beweerd dat dit afgesplitste vocabularium reeds erkend was als voldongen feit. Het resultaat is dat wij nu in productie staan met linked data die niet valideren tov. de applicatieprofielen van Besluitvorming en dossier. Een aantal fouten neem ik op mij, heb ik gelogd in jira van beleidsdomein omgeving en ik zal daar ook de nodige codewijzigingen voor doen. Alle issues die ik de afgelopen dagen op deze repo heb gelogd beschouw ik niet als mijn verantwoordelijkheid en daarvoor ben ik niet geneigd om codewijzigingen door te voeren. Mijn verwachting naar de toekomst is heel duidelijk. Er dient een transparante communicatie komen over wijzigingen die betrokkenen impacteren. Een overzicht op commits die wijzigingen veroorzaken aan rdf-modellen en shape constraints, versiebeheer in git of svn op die rdf-modellen en shape constraints (waar ik svn blame kan typen wanneer mijn code breekt) is het soort transparantie waar ik wel blij van wordt.

gezever commented 3 years ago

@dimi-schepers Onder https://data.vlaanderen.be/standaarden/ lees ik dat het einde van de publieke review van Dossier 2020-09-01 is.

bertvannuffelen commented 3 years ago

@gezever we hebben de afgelopen tijd gewerkt aan de transparantie en voor een groot deel kunnen we je vraag beantwoorden.

Voor elke (nieuwe) standaard is er een nu een duidelijke link in de specifieke naar de bron van de specieke toestand van de specificatie: Dit is het veld bron data: voor dossier is dat https://github.com/Informatievlaanderen/OSLOthema-dossier/tree/8479f32df522b087a95a65451e888ce876aefc6d Je hebt dus hiermee een ondubbelzinning zicht op de bron van de specificatie. En kan in die github geschiedenis gaan kijken naar de wijzingen (voor en na).

Op elke (nieuwe) specificatie vind je ook een verwijzing naar (eventuele) vorige en/of volgende versies van de specificatie. De wijzingen tussen de bron data links vormen de wijzigingen aan de specificatie. Merkop dat niet elke git-commit een betekenisvolle wijziging kan betekenen voor die specificatie. We laten immers toe dat er verschillende specificaties in 1 repository kunnen beheert worden. Dat is dikwijls het geval waarbij een applicatieprofiel en een vocabularium samen worden ontwikkeld. Daarnaast kunnen er ook technische ingrepen zijn: bv. ipv een png als figuur een svg als figuur opladen. Maar in elk geval heb je een interval waartussen je kan gaan kijken.

Wat je vindt in de brondata heeft rechtstreeks met de semantiek te maken. Daarnaast zijn er ook wijzigingen die helemaal niet semantisch zijn en die het gevolg zijn van het publicatie process. Wanneer we bv. de artifacts generatie tooling verbeteren dan kan dit leiden tot andere technische inhoud: denk maar aan sortering, of het toevoegen van bijkomende metadata. Dat zijn veranderingen die geen impact hebben op de semantiek. Maar wel het genereerde bestand veranderen.

Als je dus directe machinale hergebruik legt op deze bestanden en verwacht dat die 100% identiek gaan blijven (bv. je gaat ervanuit dat de sortering A->Z is) dan is het goed om met ons contact op te nemen. Want anders kunnen we je niet informeren over een potentiële impact. Als je echt wil luisteren op de gepubliceerde artifacten, die zijn ook beschikbaar in github op OSLO-generated.

gezever commented 3 years ago

Ok, dank je wel voor de toelichting Bert.