DieterDePaepe
commented
6 years ago Dag Bert,
ik heb aanpakken als optie b altijd wat vreemd gevonden, is het niet beter een eigen datatype te definiëren in de plaats?
Open bertvannuffelen opened 6 years ago
DieterDePaepe
commented
6 years ago Dag Bert,
ik heb aanpakken als optie b altijd wat vreemd gevonden, is het niet beter een eigen datatype te definiëren in de plaats?
bertvannuffelen
commented
6 years ago Dag Dieter,
niet helemaal: je kan b.v. aan de eenheid dan bv. conversie regels hangen. Een definitie en zo. En het is op zich eenvoudiger als een datatype te definiëren. Het volgt de gewone datamanagement flow.
Daarnaast, als je je eigen datatype definieert je moet beslissen of het een subtype is van een XSD:type of niet. In het laatste geval kan je dus niet van uitgaan dat er bewerken opwerken: bv. "123"^^<http://data.vlaanderen.be/datatype/meter"
Kunnen we daarmee optellen? Aftrekken?
Door het paar ("123"^^xsd:integer, "http://data.vlaanderen.be/id/maat/meter") kan je gemakkelijk bewerkingen voorzien. Je kan dus zonder type-conversie al enkele complexe vragen oplossen (zoals de gemiddelde boomomtrek) zonder dat je een interpretatie van het datatype moet doen.
Tenzij dat er een iso/w3c standaard zou zijn met maten als datatype (zoals XSD) dan lijkt het me zowel informatiegewijs als technisch het gebruiken van eigen datatypes een onnodige complexiteit.
mvg,
Bert
bertvannuffelen
commented
6 years ago Dieter,
dat laatste is misschien wel een idee om voor te dragen aan w3c...
mvg,
Bert
gezever
commented
6 years ago Ik gebruik bij omgeving een klasse Waarde met properties rdf:value en sdmxa:unitMeasure. range van sdmxa:unitMeasure is een skos:Concept dat wordt gebruikt om alle mogelijke schrijfwijzen van de eenheid te mappen naar één eenheid en te linken naar http://qudt.org/vocab/unit. vb:
dimi-schepers
commented
5 years ago In het OTL-model van AWV doen ze dit ook op een gelijkaardige manier. Het verschil is dat ze daar complexe datatypes aanmaken voor iedere mogelijke meeteenheid, bv. KwantWrdInMeter, KwantWrdInCentimeter, etc. De eenheid is dan een fixed literal. Zie Eenvoudige datatypes voor een overzicht.
Het voordeel hiervan is dat je voor iedere eigenschap strikt kan opleggen in welke meeteenheid de waarde aangeleverd moet worden.
dimi-schepers
commented
4 years ago Deze issue is besproken op de werkgroep Openbaar Domein van 8 oktober 2019. Er was een algemeen akkoord met de voorgestelde oplossing (optie b).
Men stelt voor om te werken met de Unified Code for Units of Measure code system (http://unitsofmeasure.org/ucum.html), aangezien dit ook bij AWV-OTL en bij KLIP wordt gebruikt.
Men moet de gebruiker wel de vrijheid geven om zelf de eenheid te bepalen (en dus niet de hierboven beschreven aanpak van AWV-OTL volgen). Idealiter specificeren we de mogelijke eenheden in een codelijst en geven we de best practice (op basis van het standaardbestek) mee in de usage note.
dimi-schepers
commented
4 years ago Ik zou daarom voorstellen om met de klasse KwantitatieveWaarde (https://schema.org/QuantitativeValue) uit OSLO-Generiek te werken.
Beste,
ik lees in het openbaardomein enkele eigenschappen die naar waarden met meeteenheden verwijzen. b.v. boomomtrek. Ik denk dat hier heel duidelijk moet beschreven worden in welke maat er gemeten wordt. Er zijn twee opties hier:
a) per definite: boomomtrek heeft als range double met als eenheid meter. (**) b) als modelering: boomomtrek heeft als range een Lengte_eenheid_maat_waarde waarbij een Lengte_eenheid_maat_waarde een paar is (waarde, eenheid) waarbij eenheid een lengte maat is.
(**) hierbij moet altijd gekozen worden voor de meest precieze voorstelling (een double) omdat er misschien iemand is die preciesere meetingen wil doen en deze ook meedelen. Indien voor b.v. een integer wordt gekozen dan is het aangeraden om na te denken hoe op een generieke wijze een meer preciese waarde kan worden meegegeven.
mvg, Bert