OpenCatalogi
Welke data willen we metadateren? #10
-
|
Onder #7 #85 #85 #67 #75 en #67 wordt er gevraagd naar het metadateren van gevens. Die roept de vraag op welke metedata willen we over componenten, modelen, processen en documentatie opslaan? We kunnen hiervoor naar een aantal voorbeelden en bronnen kijken
In een bredere context raakt dit wellicht ook aan de wet openbaarheid bestuur Voor het datamodel zullen we in eerste instantie te kijken naar wat er nu al gebruikt wordt om componenten en applicaties te omschrijven en daarop uit te breiden indien nodig aan de hand extra eisen (UPL namen bijvoorbeeld). Start is dan even de huidige componenten catalogus. Die heeft een relatief simpele opbouw. {
"id": 19,
"name": "Adresservice",
"layerType": "services",
"description": "Dit component verrijkt huisnummer en postcodes bevragingen met BAG gegevens.",
"organisationName": "Conduction",
"contact": "[ruben@conduction.nl](mailto:ruben@conduction.nl)",
"repositoryUrl": "https://github.com/ConductionNL/adresservice",
"reuseType": "zelf installeren",
"expectedQuarter": null,
"expectedYear": null,
"developedBy": null,
"status": "bruikbaar",
"owner": {
"id": 5,
"fullName": "Ruben van der Linde",
"email": "[ruben@conduction.nl](mailto:ruben@conduction.nl)",
"pictureUrl": "https://account.pleio.nl/media/avatars/2019/07/04/60221507/large_jjMfUkz.jpg"
},
"createdAt": "2020-02-18T10:37:28.710861Z"
}Kijken naar voorliggende user stories is dat te weinig informatie. Een meer waardevolle standaard lijkt publiccode te zijn. Voorstel is dan ook om publiccode van een yaml naar api om te slaan, en uit te breiden met de twee properties uit de componenten catalogus die we dan missen (layerType en installationType) vanuit de huidige componenten catalogus. De publiccode standaard ondersteund landspecifieke afwijkingen. Dus daar kunnen we ze onder opnemen. Dan eindigen we met deze specs wat ons als voorbeeld opleverd: {
"id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",
"name": "Medusa",
"applicationSuite": {
"id": "string",
"name": "string"
},
"url": "https://example.com/italia/medusa.git",
"landingURL": "https://example.com/italia/medusa",
"isBasedOn": "https://github.com/italia/otello.git",
"softwareVersion": "1.0",
"logo": "https://avatars0.githubusercontent.com/u/34739001?s=280&v=4",
"releaseDate": "2022-01-01",
"platforms": "web",
"categories": [
"Acounting"
],
"usedBy": [
"City of Amsterdam"
],
"roadmap": "https://vng.nl/agenda",
"developmentStatus": "concept",
"softwareType": "standalone/web",
"layerType": "interface",
"installationType": "self",
"intendedAudience": {
"countries": [
"nl"
],
"unsupportedCountries": [
"de"
],
"scope": [
"agriculture",
"culture"
]
},
"description": {
"NL": {}
}
}Voor componenten zijn we dan redelijk los, we missen echter nog wat details Vanuit public code zit een component vast aan één applicatie, vanuit commonground is dat eigenlijk omgekeerd en bestaad één applicatie uit meerdere componenten waarbij één component in meerdere applicaties kan voorkomen. Dat pleit er voor om van applicationSuite een object te maken ipv een sting (reeds verwerkt in voorbeeld api), dat object bestaad nu uit een naam maar bestaad in de huidige componenten catalogus api uit veel meer details. {
"id": 3,
"name": "API Testvoorziening",
"shortDescription": "Platform om consumers enproviders van API’s te testen",
"description": "Platform om consumers en\r\nproviders van API’s te testen",
"detailPageImageUrl": "https://d5622d88f45b4d1fb8a6bc6d33bce28b.objectstore.eu/public/api-test.png",
"documentationUrl": "https://github.com/VNG-Realisatie/api-test-platform",
"demoUrl": "https://api-test.nl/",
"bpmnProcessUrl": "",
"isPublished": true,
"owner": null,
"components": []
}Een aantal van deze properties zullen we moeten overnemen in het application object. Op dit moment zijn zowel publiccode als de componentencatalogus best ambigue met betrekking tot ownerschip en organisaties. De componenten catalogus kent owners als conctactPersoon objecten, publiccode doet voor hetzelfde maar hanteerd voor maintanance dan weer contractor objecten. Hier moeten we even over nadenken het voelt logisch om het te hebben over organisaties die componenten maken, ontwikkelen, beheren en gebruiken. Maar wat doe we dan met personen die componenten ontwikkelen? Out of scope verklaren? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
|
Would be best to get the So instead of:
=>
|
Beta Was this translation helpful? Give feedback.
-
|
This is a commonground component catalouge thing do, in public code this is a object |
Beta Was this translation helpful? Give feedback.
-
|
Ik weet niet goed waar bovenstaande technische verhandeling over gaat... Onze productowner heeft een eerste aanzet aan attributen al uitgewerkt. Dit per laag van het 5-laagse model. Dus als het gaat om 'welke data willen we metadateren' moeten we denk ik dicht blijven bij de componenten die zich in die lagen bevinden. We hebben toen ook gekeken naar de huidige componenten catalogus, dus voorstel is om éérst uit te gaan van de set van Ronald. |
Beta Was this translation helpful? Give feedback.
-
|
@RonaldvCortenberghe waar kunnen we jouw set vinden? |
Beta Was this translation helpful? Give feedback.
-
|
Oke ik heb een mapping gemaakt van de set van @RonaldvCortenberghe naar de PublicCode Metadata en die her en der al wat uitgebreid Op dit moment kan ik twee dingen niet zo goed kwijt
|
Beta Was this translation helpful? Give feedback.
-
|
Vragen:
Besloten bovenstaande tabel als basis te gebruiken voor metadatering. |
Beta Was this translation helpful? Give feedback.
-
|
Laag 3 en 5 nog toevoegen aan de tabel. Daarbij geldt voor laag 5 dat 'thema/doel/onderwerp' ingevuld wordt door Gemma 'bedrijfsfunctie' en 'bedrijfsservice' |
Beta Was this translation helpful? Give feedback.
Oke ik heb een mapping gemaakt van de set van @RonaldvCortenberghe naar de PublicCode Metadata en die her en der al wat uitgebreid
Op dit moment kan ik twee dingen niet zo goed kwijt