search

Informatievlaanderen / OSLO-toolchain

2 stars 0 forks source link

Naamgeving elementen contextfile. #41

Closed GeertThijs closed 4 years ago

GeertThijs commented 4 years ago

Link waar het probleem zich voor doet: Contextfiles.

Omschrijving van het probleem: De naam vh element in de contextfile verschilt soms vd werkelijke naam vh element. Dit is verwarrend.

Omschrijving van een mogelijke oplossing: Aanpassen.

bertvannuffelen commented 4 years ago

updated context generator heeft nu opties om de term te configuren

Usage: json-ld-generator node specgen-context.js creates a json-ld context

Options:
  -V, --version            output the version number
  -i, --input <path>       input file (a jsonld file)
  -o, --output <path>      output file (the context)
  -d, --forceDomain        force the domain all the terms, instead only for those that are necessary. Default false
  -l, --useLabels <label>  the terms used are { label = the labels in camelCase, uml = the names from the UML},
  -h, --help               output usage information

Examples:
  $ specgen-context --help
  $ specgen-context -i <input> -o <output>
  $ specgen-context -i <input> -o <output> -l label
GeertThijs commented 4 years ago

Heel goed. Maar met welke parameters draaien we nu best?

GeertThijs commented 4 years ago

Oké, ik probeer zelf te antwoorden. Als ik naar de huidige output kijk denk ik dat je draait met opties -i -o -l uml, kan dat? Maw: 1) je forceert enkel een domein op de mapping-term als dat nodig is. Bv wel op gerealiseerdOp omdat er zowel een Routesegment.gerealiseerdOp en een Routeknoop.gerealiseerdOp is met elk een eigen uri? (Anders zou laatstvermelde mapping de vorige overschrijven en krijg je foute mappings.) Maar niet op type omdat deze toch steeds naar dcterms:type wijst. En 2) je haalt de mapping-term uit het UML-diagram?

GeertThijs commented 4 years ago

Persoonlijk zou ik de opties -i -o -d true -l label prefereren. 1) De contextfile zal er langer door worden, bv type zal meerdere keren voorkomen, bv een keer als Transportknoop.type en als Transportgebied.type, allebei mappend naar dezelfde dcterms:type. Technisch is dat echter geen probleem volgens mij en de leesbaarheid van het bestand neemt er drastisch door toe. Nu heb je de neiging als je ergens x.type ziet staan om ook y.type te zoeken. Of zelfs als je x.a ziet om ook y.b te verwachten en niet ineens b zonder prefix. 2) Labels ipv uml-names is ook logischer aangezien de contextfile een vertaling is vh UML-diagram naar RDF. En daar worden associaties attributen, bv een associatie Reiziger-Onderneemt-Reis wordt Reiziger.onderneemt. Wel omzetten in camelCase inderdaad, bv "Gerichte link" wordt GerichteLink en "bestaat uit" wordt bestaatUit.

mvanbrab commented 4 years ago

Ik leun aan bij de keuze voor "altijd domeinnaam prefix" en "namen op basis van labels, op voorwaarde van door Geert veronderstelde camelCase conversie".

Dit is wel 180° verschillend van wat er gegenereerd wordt na de toolchain update van een uur geleden. Bijvoorbeeld: https://github.com/Informatievlaanderen/OSLO-Generated/blob/c9b8b2fbe061ddd11c6a27e61707cf24175cad6a/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/kandidaatstandaard/2020-04-15/context/mobiliteit-trips-en-aanbod-ap.jsonld

Ter vergelijking, vóór toolchain update was dit: https://github.com/Informatievlaanderen/OSLO-Generated/blob/b39bedfd21dd1281151c89141703ab96ac009d95/doc/applicatieprofiel/mobiliteit-trips-en-aanbod/kandidaatstandaard/2020-04-15/context/mobiliteit-trips-en-aanbod-ap.jsonld

Het lijkt me dat in de deze laatste zelfs meer domeinnaam prefixen stonden, bvb.: "Aanbieder.^contactinfo".

Laat ons op basis van een vergelijking in deze twee bestanden een discussie opstarten (mondeling).

mvanbrab commented 4 years ago

For the record: na aanpassing op test-feature-checkout branch zodat de juiste opties werden meegegeven (-d true -l label) is dit OK. Gaf nog andere .jsonld die volledig voldeed.