Issue with Measure

[GeertThijs]

There are some issues with Measure:

• INSPIRE uses Length as the datatype of HeightAboveGround.value, BuildingGeometry.horizontal/verticalGeometryReference. Measure is the superclass of Length and so would allow inapropriate subtypes like Angle, Speed etc.
• The definition of INSPIRE-base:Measure does not fit the current implementation, it is defined as a serialisation of value and unit (eg" 90 m"), not as a structured datatype with a value and a unit as seperate attributes. ISO19103:Measure is a structured datatype with a value and a unit modelled as seperate attributes.
• The fact that Length does not exist in INSPIRE-base does not justifiy to substitute it for Measure. Moreover, INSPIRE-Building refers to ISO19103:Length, probably the reason why INSPIRE-base only has Measure and no subtypes like Length, Angle, Speed etc.
• ISO-base nor ISO19103 uri's are officially published, however ISO19103 uri's are more recent and better established.
• Why map Measure.value to qudt:value and mint a vocab.belgif uri for Measure.uom while there exists a qudt:unit? And if ISO19103 would be used there is ISO19103:Measure.value and ISO19103:Measure.uom.
• The current solution however has the advantage of describing the unit by a skos:Concept, rather than the String proposed in ISO19103 (implicitly referring to unitcodes of ISO2955, eg "m" for meter). It implies however that such a codelist should be provided or an existing one is used (like the one from qudt).

[GeertThijs]

In a data-example the solution with ISO19103:Length would look like this: { "@context": { "@vocab": "https://example.com/ns/", "iso": "http://def.isotc211.org/iso19103/2015/MeasureTypes#" }, "length": { "@type": "iso:Length", "iso:Measure.value": 90, "iso:Length.uom": { "@type": "iso:UomLength", "iso:UnitOfMeasure.uomIdentifier": "m" } } } The current solution looks like this: { "@context": { "@vocab": "https://example.com/ns/", "inspire-base": "http://inspire.ec.europa.eu/ont/base#", "iceg-building": "http://vocab.belgif.be/ns/building", "qudt": "https://qudt.org/schema/qudt/", "skos": "http://www.w3.org/2004/02/skos/core#" }, "length": { "@type": "inspire-base:Measure", "qudt.value": 90, "iceg-building:uom": { "@type": "skos:Concept", "@id": "https://example.com/concept/unittype" } } }

[GeertThijs]

Actually OSLO analysed several possibilites to model quantitative values like Length. We advise solution no 5 or 6. Solution 5 is based on a value and unit structure with a unit as a string according to ucum (= ISO2955 symbols) and 6 is also a value and unit structure with a skos:Concept for the unit based on qudt. I would advise to go with the ISO19103 solution which is very similar to solution 5 or with solution 5 or with solution 6. INSPIRE-base:Measure is defined according to solution 2 (value and unit in the same string), but has been implemented by ICEG-building as solution 6 but mapped to qudt for the value and a ICEG uri for the unit.

[bahimc]

The proposed ISO solution for the issue has a problem with how units of measure are classified. They are currently listed as strings, which allows for any value to be entered. Additionally, the ISO Length class is described as abstract, meaning that a specific implementation is needed. Using QUDT, which is an industrial specification, is not in line with INSPIRE standards, as INSPIRE uses GML measures and OGC standards. The use of QUDT also does not align with the European classification of units of measure, which can be found at https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/measurement-unit. Therefore, the solution proposed to use the base:Measure class with the properties qudt:value and iceg-building:uom is a compromise, as the original definition of base:Measure is focused on text representation rather than structured values.

[GeertThijs]

Here more verbose the reasons why NOT to use inspire-base:Measure:

• Inspire-base:Measure is defined on github as "a text representation of a measure value. The decimal value is followed by a space and the unit of the measure". So the definition suggests using a string with value and unit, eg "90 m". This does not comply with the ICEG implementation that (rightly so) describes value and unit with seperate attributes.
• Inspire-base was updated july 2017 and remained stuck in version 0.1.0 since then. ISO19103 may not be finalised either, but was last updated march 2022. I would put a lot more trust in the ISO TC211 RDF initiative than in that of INSPIRE
• But more importantly: Inspire-base:Measure and ISO19103:Measure are actually equivalent. Check for example the INSPIRE consolidated model to find out that INSPIRE uses the TC211 models as base for its own model. ISO19103:Measure is the datatype of many attributes and its subclass ISO19103:Length is the datatype of INSPIRE-Building:HeightAboveGround.value (see attributes of INSPIRE:HeightAboveGround). All this is confirmed in the INSPIRE2RDF Guidelines in this paragraph.
• It is true that ISO19103:Length is abstract, but so is ISO19103:Measure (and thus Inspire-base:Measure as it is equivalent). Semantically speaking Measure is even more abstract than Length (if it would be possible to say something like that), as the latter is much more specific and can be used without further subclassing.
• The fact that ISO:19103 defines a Measure by describing value and unit seperately fits the ICEG definition much better because, as said above, Inspire-base:Measure allows things like "90 m".
• If by now you are convinced not to use Inspire-base:Measure but rather ISO19103:Measure why not use ISO19103:Measure.value in stead of qudt:value. Altough both are perfectly equivalent, there is no reason to involve qudt in the model if you are not going to use qudt:unit.
• There can be discussion indeed if you want something like "m" (based on the ISO2955 unit symbols) as unit or rather something like "http://publications.europa.eu/resource/authority/measurement-unit/MTR". This is similar to the discussion if one should use languagecodes like "nl" or an uri for the language. OSLO allows both as you can see in OSLO Generiek where we allow StandaardEenheid to be a Literal or a URI. (Only problem there is that we use schema.org:QuantitativeValue in stead of ISO19103:Measure, this should be changed.)
• It is correct that using qudt:unit would imply a datatype qudt:Unit as this is explicitly stated to be the rdfs:range of qudt:unit. So something like iceg-building:uom is indeed better (OSLO used schema.org.unitCode).
• Range in the ICEG model is skos:Concept which is best in the ideal world where units are published as skos:Concepts. However, for example in the Named Authority List you mentioned above I only found HTML renderings for the units, nothing in RDF. So URI as range would be more practical, this would also allow to the qudt Units which are instances not of skos:Concept but of the owl:Class qudt:Unit. As already said, in OSLO Generic we went a bit further and created a datatype OSLO:StandardUnit as range which allows to be substituted by URI or Literal (Literal to allow also the above mentioned string option like the one of ISO19103 or UCUM).
• I think it is very important to allow for several possible solutions here as for example the Named Authority List you mentioned, even if it would contain skos:Concepts, is very short, it contains only 51 units. Some would prefer to use qudt for example as it contains 1773 units. It is true that only Length units are needed in ICEG Building but in future ICEG models you will need other quantitykinds expressed in units which are possibly not in that list.

[bahimc]

The conclusion of this comment is that the use of Inspire-base:Measure is not recommended in favor of ISO19103:Measure, as the latter is more compliant with the ICEG implementation and is the datatype of many attributes in the INSPIRE model. Additionally, it is recommended to use ISO19103:Measure.value instead of qudt:value, and to allow for different solutions for unit representation, such as using qudt, URI or Literal, as there are various options available, and the use of a specific one will depend on the specific use case. We agree with the first two points mentioned however, ISO19103:Measure.value is an object property and therefore qudt:value is better as being a generic property. Our stance is that ICEG should what is there at European level first, and reuse controlled vocabularies from the Publications Office when possible. Our proposed resolution would be to reuse QUDT:value or create a new property, which would allow to have control over the definiton.

[GeertThijs]

• Glad that you will use the real iso:Measure in stead of the INSPIRE version of it. We use it also in our version of ISO Observations & Measurements. Apart from that we also use schema.QuantitativeValue, which is equivalent.
• Qudt:value is indeed more generic than iso:Measure.value as it has no range, altough I do not see where else it could be used than in the context of a Measure or QuantitativeValue. It is defined as "A property to relate an observable thing with a value of any kind", so it is not so generic as for example rdf:value. We use iso:Measure.value in our version of ISO Observations & Measurements.
• It is not clear for me now what you will use for the unit, which should be a seperate attribute. Qudt:unit would imply the use of qudt:Unit, which is a subclass of skos:Concept. Yoy could use the instances of qudt:Unit, or another one (eg the European NAL you mentioned). Or you could define your own attribute iceg:unit with range iceg:Unit and allow iceg:Unit to be substituted by URI or Literal. The URI can then point to any skos:Concept or even instances of Classes, the typed string would allow for strings like "m" from ISO2955 or ucum codes. (This is what we did.) Or you could provide both these possibilities as seperate attributes. The qudt:unit solution would be the easiest I think, combined with an ap-codelist tag that points to the European NAL as the preferred one.

[bahimc]

We agree that Qudt:value is more generic than iso:Measure.value and that it could be used in the context of a Measure or QuantitativeValue. Also, QUDT:Unit is not a subclass of skos:Concept. So, we would therefore opt for defining our own attribute (iceg:unit) while using the European NAL database of measurement units, as it provides a centralized reference of measurement units and their properties. Do you agree with the suggestion?

[GeertThijs]

• What I mean is that altough iso:Measure is less generic than qudt:value, there is no need for it to be more generic. So iso:Measure would be perfectly fine. But qudt:value is ok too if you do not mind to do different than Flanders.
• You are right that qudt:Unit is not a subclass of skos:Concept, it is a subclass of qudt:Concept which is not 100% the same. So indeed if you insist on using a skos:Concept as range you should create your own iceg:unit.
• It is indeed possible to advise a certain codelist for something by adding the ap-codelist tag to the attribute. I am just not sure that the NAL you refer to is published as a skos:Conceptscheme with skos:Concepts. You should verify that to be sure.