Amsterdam Ordnance System (mNAP) as QUDT submission

[RiX012]

We are using QUDT a lot, but we are struggling with a Vertical CRS which we use in the Netherlands. This is properly defined in https://epsg.io/5709. But I want to use it together with qudt:hasUnit in my data (instead of ‘GeoWKT’).

I made this but I am not sure if it is correct. And therefore I don’t want to do a pull request (yet). Could somebody help me in the right direction? Thanks.

@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix epsg: <http://www.opengis.net/def/crs/EPSG/0/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix example: <http://example.org/try-out/>  .

example:MeterRelativeToNAP a qudt:Unit, geo:CoordinateReferenceSystem ;
    rdfs:seeAlso <https://epsg.io/5709> ;
    rdfs:label "Meter relative to NAP"@en ;
    qudt:symbol "m NAP" ;
    qudt:abbreviation "m NAP" ;
    rdfs:comment "Height in meters relative to the Normaal Amsterdams Peil (NAP)"@en ;
    qudt:conversionOffset "0.0"^^xsd:double ;
    qudt:conversionMultiplier "1.0"^^xsd:double ;
    qudt:baseUnit unit:M ;
    qudt:quantityKind quantitykind:Height ;
    qudt:ucumCode "m{NAP}" ;
    qudt:hasReferenceSystem example:NAP ;
    dcterms:identifier "EPSG:5709" ;
    geo:asWKT "VERTCRS[\"NAP height\",VDATUM[\"Normaal Amsterdams Peil\"],CS[vertical,1],AXIS[\"gravity-related height (H)\",up,UNIT[\"metre\",1]]]"^^geo:wktLiteral ;
    epsg:areaOfUse "Netherlands - onshore." ;
    epsg:scope "Engineering survey, topographic mapping." .

example:NAP a qudt:ReferenceSystem ;
    rdfs:label "Normal Amsterdam Level"@en ;
    rdfs:comment "The zero point and reference level for height measurements in the Netherlands"@en ;
    qudt:hasUnit example:MeterRelativeToNAP ;
    dcterms:identifier "EPSG:5709" ;
    skos:closeMatch <http://www.opengis.net/def/datum/EPSG/0/5709> .

[steveraysteveray]

Thanks for your inquiry, and for your decision to adopt QUDT!

I have two comments right away:

1. MeterRelativeToNAP conflates the concepts of a Unit and a QuantityKind. I suggest you define quantitykind:HeightRelativeToNAP, and then you can use any length unit you like, including metre (unit:M) as your unit. In your definition of quantitykind:HeightRelativeToNAP, use skos:broader quantitykind:Altitude (or quantitykind:Height if you prefer). That way, it will acquire the applicableUnits used by Altitude (or Height) the next time we publish a Release. Also, please take a look at our guidance here.
2. We do not have a class qudt:ReferenceSystem defined in QUDT, so your instantiation of example:NAP will fail. We do define qudt:ReferenceFrame in the http://qudt.org/2.1/schema/datatype graph, although we haven't refreshed it for years. I think it might meet your needs. If this is a priority for you, perhaps we should discuss.

[RiX012]

@steveraysteveray thanks for your quick response!

1. MeterRelativeToNAP conflates the concepts of a Unit and a QuantityKind. I suggest you define quantitykind:HeightRelativeToNAP, and then you can use any length unit you like, including metre (unit:M) as your unit. In your definition of quantitykind:HeightRelativeToNAP, use skos:broader quantitykind:Altitude (or quantitykind:Height if you prefer). That way, it will acquire the applicableUnits used by Altitude (or Height) the next time we publish a Release

1. Ok, that's seems logical indeed. I should use qudt:applicableUnit instead of qudt:baseUnit then right? I feel that in this case Heigt is more appropriate than Altitude. But the semantics of Altidude are closer to that what the NAP is about.
2. When using qudt:Altitude, there should still be a link established with the CRS (http://www.opengis.net/def/crs/EPSG/0/5709) right? I am not sure QUDT does provide a method for this? It could be done via dct:conformsTo in the metadata. I guess the question it: is there a preferred method for specifying a datum for qudt?
3. All properties like qudt:symbol, qudt:abbreviation, qudt:conversionOffset, qudt:conversionMultiplier and qudt:ucumCode can then be considered absolute?

2. We do not have a class qudt:ReferenceSystem defined in QUDT, so your instantiation of example:NAP will fail. We do define qudt:ReferenceFrame in the http://qudt.org/2.1/schema/datatype graph, although we haven't refreshed it for years. I think it might meet your needs. If this is a priority for you, perhaps we should discuss.

My mistake. It was indeed qudt:ReferenceFrame what I meant.

Is the snippet below moving in the right direction?

@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix quantitykind: <http://qudt.org/vocab/quantitykind/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix epsg: <http://www.opengis.net/def/crs/EPSG/0/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix example: <http://example.org/try-out/> .

example:HeightRelativeToNAP a qudt:QuantityKind ;
    rdfs:label "Height relative to NAP"@en, "Hoogte ten opzichte van NAP"@nl ;
    rdfs:comment "Height measurement relative to the Normaal Amsterdams Peil (NAP)"@en , "Hoogtemeting ten opzichte van het Normaal Amsterdams Peil (NAP)"@nl ;
    skos:broader quantitykind:Altitude;
    qudt:referenceFrame example:NAP ;
    qudt:applicableUnit unit:M .

example:NAP a qudt:ReferenceFrame, geo:CoordinateReferenceSystem ;
    rdfs:label "Normaal Amsterdams Peil"@nl , "Normal Amsterdam Level"@en ;
    rdfs:comment "Het nulpunt en referentieniveau voor hoogtemetingen in Nederland"@nl , "The zero point and reference level for height measurements in the Netherlands"@en ;
    dcterms:identifier "EPSG:5709" ;
    skos:closeMatch <http://www.opengis.net/def/datum/EPSG/0/5709> ;
    geo:asWKT "VERTCRS[\"NAP height\",VDATUM[\"Normaal Amsterdams Peil\"],CS[vertical,1],AXIS[\"gravity-related height (H)\",up,UNIT[\"metre\",1]]]"^^geo:wktLiteral ;
    epsg:areaOfUse "Netherlands - onshore." ;
    epsg:scope "Engineering survey, topographic mapping." .

[steveraysteveray]

1.1. Yes, applicableUnit is the right relation. You could include some applicableUnit triples in your PR, but recognize that all the applicableUnit relations are regenerated with each new Release, as documented here. This is why I recommended you include the skos:broader relation, which then will drive the generation of applicableUnit relations for your new quantity kind. I recommend your quantity kind use skos:broader to quantitykind:Altitude.

2. Your question brings up an interesting issue that we have neglected so far, which is the use of schema/SCHEMA_QUDT-DATATYPE-v2.1.ttl and vocab/types/VOCAB_QUDT-DATATYPES-v2.1.ttl. These two files are in the GitHub repository, but are currently not part of the official Release each month, because as I mentioned, we have not revisited this work for years. However, in vocab/types/VOCAB_QUDT-DATATYPES-v2.1.ttl you will find 6 instances of qudt:EarthCoordinateSystem, each of which references an instance of a qudt:ReferenceFrame (or a subclass of qudt:ReferenceFrame). The best approach would be for you to define another instance of qudt:ReferenceFrame (or one of its subclasses). If you look at the other instances, you will see that they have relations that allow you to point to your information. I am by no means an expert on the coordinate systems and reference frames we already have, so I would ask you to determine if you need to define new instances of each for your application. The larger issue for us is whether it is now time for us to add the datatypes schema and vocabulary files to the normal QUDT release moving forward. It would take a bit of time because they currently do not pass our validation rules.
3. I'm not sure what you mean by absolute, but the relations you list are for instances of qudt:Unit. I believe all you would be defining is a new qudt:QuantityKind. We then need to figure out what adjustments are needed in our core schema to tie in a pointer to the appropriate coordinate systems and reference frames from our QuantityKind class.

All of my suggestions above are my best guess on the use of the coordinate systems. Some of the members of our Technical Advisory Board work in the geosciences field, so I would ask them to please weigh in if I have made any errors above. However, I thank you for bringing these issues up, because they will make QUDT all the more useful.

[dr-shorthair]

'Elevation' is probably a better name for the quantity kind.

However, I'm a little nervous about getting into coordinates, which are not the same as quantities. Different operations apply to coordinates: addition and subtraction, but not multiplication and division. Coordinates have a datum and direction, which is not part of the definition of quantity kinds.

(Celsius and Fahrenheit temperatures are coordinates while thermodynamic temperature is a quantity.)

[RiX012]

Thanks for your reactions. I talked with some colleagues about your suggestions and reviewed our options.

• Elevation is indeed better.
• The skos:broader relation is a good one and we will keep that
• 'absolute', had to be 'obsolete' (sorry, not native in English :-) )
• And indeed we only need quantityKind

I also agree with @dr-shorthair that it feels a bit strange to do it like this. Having said that, mNAP is the only concept that is not defined in QUDT from what we need. So instead of dragger another ontology in the mix I would prefer to do it like this. Next to that I could not find an ontology which defines such a concept.

[steveraysteveray]

I think you are heading in the right direction. If you propose your new QuantityKind in a PR, I'll be happy to take a careful look.