search

qudt / qudt-public-repo

QUDT -Quantities, Units, Dimensions and dataTypes - public repository
Other
114 stars 71 forks source link

quantitykind:Altitude vs Latitude, Longitude; related quantitykinds #379

Open VladimirAlexiev opened 3 years ago

VladimirAlexiev commented 3 years ago

There is quantitykind:Altitude, a specialization of quantitykind:Length

quantitykind:Altitude
  qudt:hasDimensionVector <http://qudt.org/vocab/dimensionvector/A0E0L1I0M0H0T0D0> ;
  skos:broader quantitykind:Length ;

But there aren't Latitude, Longitude as specializations of Angle I find this inconsistent. Please decide whether to create Latitude, Longitude or to drop Altitude.

Also, there aren't Speed of ascent, Speed of descent as specializations of Speed. But I feel less strongly about this, because there'd be no end (we can then have "acceleration of descent", etc etc).

--

Are there any principles when to create quantitykind "specializations"?

I was surprised to find that the dimension vectors of some quantity kinds and their specializations are different, eg:

In general, I think the following quantity kinds need to be examined:

steveraysteveray commented 3 years ago

@VladimirAlexiev, many good points, as usual.

dr-shorthair commented 3 years ago

Altitude, latitude, longitude are not specializations of length, they are specializations of position. There is a datum (offset) and direction involved, whereas length is an absolute quantity.

Geometry is complicated. There are detailed standards available from OGC and ISO. For coordinate systems which are required for elevation/latitude/longitude/easting/northing etc - see ISO 19111:2018 (the link is to OGC version which is not paywalled).

VladimirAlexiev commented 3 years ago

@dr-shorthair I was just about to write that if we introduce Latitude, Longitude, we should make them abstract quantitykinds, with two specializations:

But this wouldn't express the origin:

Converting between CRS'es is a complicated matter and I don't think QUDT wants to replicate all the CRS info and conversion algorithms collected by OGC.

Altitude, latitude, longitude are not specializations of length, they are specializations of position.

But there's no quantitykind Position and if there were, it would be extremely abstract because there are so many ways to position yourself in the universe.

@nicholascar what do you think?

nicholascar commented 3 years ago

I don’t thing QUDT should move into the spatial space, other than listing spastic UoMs.

I’ve urged OGC to look to signing up to the QUDT consortium to assist in maintaining QUDT and to influence its governance, but the expected way forward here is for QUDT to stick to metrology and for OGC to use QuDT for all units etc.

Perhaps, in the fullness of time, QUDT might become an OGC standard... It would not be the first time an externally-developed thing became a standard (think KML, GeoJSON, etc).

dr-shorthair commented 3 years ago

@VladimirAlexiev yes, altitude/elevation/depth/latitude/longitude/easting/northing might be conceptualized as quantity-kinds, but we do need to be careful about confusing quantities and coordinates. I feel that QUDT should probably focus on scalar quantities, and leave coordinates to the more specialized communities that use those routinely. In the case of altitude/elevation/depth/latitude/longitude/easting/northing there is a respectable and rigorous organization that is doing this - OGC.

VladimirAlexiev commented 3 years ago

@dr-shorthair @nicholascar So your opinion is to kill quantitykind:Altitude? I agree.

About OGC adoption: GS1 are hesitant to adopt QUDT because it's not vetted by a Standards-Developing Organization (SDO). At least they'll conform their developing list of 71 MeasurementTypes to QUDT's quantityKinds (see https://github.com/gs1/EPCIS/issues/248), but I think will copy them to a gs1:QK- namespace, believing that will bring them more assurance and stability.

I tried to convince them that the best way to ensure QUDT stability and evolution is to contribute to it, not just copy from it. I tried to convince them to step in to fill the former role of NASA, but ... I think that if OGC steps in, GS1 will follow suit, and we'll all have one big happy family.

dr-shorthair commented 3 years ago

Yes - I think it would be best if QUDT removed quantitykind:Altitude - it is outside the scope of QUDT.

nicholascar commented 3 years ago

I agree with Simon

steveraysteveray commented 3 years ago

Very interesting discussion, and thanks to @nicholascar and @VladimirAlexiev for advocating for more direct involvement by OGC and GS1 to help QUDT remain a viable and sustainable infrastructure upon which others can build. We do in fact have infrastructure costs to keep QUDT going, which currently come out of our personal pockets, and none of us are paid to work on QUDT, so support by helping with contributions, or with cold hard cash makes a big difference!

To the subject at hand, if we remove quantitykind:Altitude, then by the same logic would we not also remove quantitykind:Temperature? It exhibits the same behavior - units are scales with a datum (Celsius,...) just like units of Altitude. Just looking for consistency here.

JoelBender commented 3 years ago

DEG_C has a quantitykind Temperature but not a ThermodynamicTemperature. It also has a quantitykind CelsiusTemperature, but it's the only one that is, and I would have expected MilliDEG_C to have one.

jhodgesatmb commented 3 years ago

So altitude is not a quantity kind? It is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind. I have often wondered why there is no width, breadth, or height (oops, both width and breadth exist) quantity kinds in QUDT. I didn’t chime in on the early discussion about latitude and longitude but I am keen to hear the reasoning for altitude. By the way, we collect quantity kinds from various sources and some of them have questionable value. Altitude doesn’t appear to be questionable.

I have always thought of altitude as radial distance from some place on the ‘ground’ to some place above the ground. As a pilot I refer to altitude as AGL (above ground level) or MSL (above sea level), but have never heard of it used in the context of a position. You could say that, at an altitude, you would have a position, but they aren’t the same.

I do see latitude and longitude as angular coordinate components of position, but they are only a position when both are provided. Otherwise they are angles.

Jack

Sent from my iPad

On Apr 17, 2021, at 8:47 PM, Joel Bender @.***> wrote:  DEG_C is a Temperature but not a ThermodynamicTemperature.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

nicholascar commented 3 years ago

To the subject at hand, if we remove quantitykind:Altitude, then by the same logic would we not also remove quantitykind:Temperature

The decision to include or remove a domain from QUDT is surely only related to scientific considerations. Surely the absence or presence of other, related, actors in the Semantic Web are important too, since multiple organizations have their parts to play in this networked information.

So here, the fact that the OGC (and even the ISO TC211) exist and are involved with Semantic Web things has bearing on QUDT's decisions around quantitykind:Altitude. Surely if Altitude and other spatial things are "adequately handled" from a Semantic Web viewpoint, then QUDT shouldn't move into that space. If not, then it should. Same for temperature: is there a standards or other organization with a good Semantic Web handling of temperature such that QUDT need not implement things?

My best guess is that QUDT should work with temperature and probably is already the Semantic Web's go-to place for temperature quantity kinds, units etc. but that QUDT should not work to replicate Semantic Web spatiality, given the OGC and other's long-time work in the field. As Simon's noted above, perhaps QUDT can stick to scalar values?

Current work with GeoSPARQL 1.1 is introducing a SpatialMeasure class and right this week I'm working on examples of QUT scalar measurements using SpatialMeasure alongside GeoSPARQL Geometry examples which, hopefully, both QUDT and OGC people can comment on. GeoSPARQL 1.1 will be out for full public review shortly, so please do weigh in officially on that draft.

jhodgesatmb commented 3 years ago

I am in favor of standards organizations taking up the gauntlet of trying to standardize a quantity, unit, and dimension semantic pattern and to standardize vocabularies to that pattern. I am not in favor of carving it up into pieces and laying some kind of claim to those pieces. QUDT is intended to support the existing systems of units and quantity kinds and to provide conversion between them. QUDT has also pledged to provide cross references to other vocabularies. QUDT has been liberal in allowing people (subject matter experts in their fields) to submit units and quantity kinds for inclusion into the vocabularies. Finally, QUDT has also allowed for QuantityKind classes to be customized, and that opens the door to all kinds of use. If anything, QUDT is about broadening coverage and being more inclusive.

So if altitude is a commonly used quantity kind, it is measurable, and it has a dimension vector, I see no issue with it.

QUDT represents many data types and that is why we have a datatype schema. You are suggesting that there not be a common representation pattern and associated vocabularies but I would disagree. That some organization chose to carve out a piece of a whole doesn’t make it right. We should integrate the various models and vocabularies and not tear them apart. That sounds like politics and not like science.

Sent from my iPad

On Apr 17, 2021, at 10:26 PM, Nicholas Car @.***> wrote:

 To the subject at hand, if we remove quantitykind:Altitude, then by the same logic would we not also remove quantitykind:Temperature

The decision to include or remove a domain from QUDT is surely only related to scientific considerations. Surely the absence or presence of other, related, actors in the Semantic Web are important too, since multiple organizations have their parts to play in this networked information.

So here, the fact that the OGC (and even the ISO TC211) exist and are involved with Semantic Web things has bearing on QUDT's decisions around quantitykind:Altitude. Surely if Altitude and other spatial things are "adequately handled" from a Semantic Web viewpoint, then QUDT shouldn't move into that space. If not, then it should. Same for temperature: is there a standards or other organization with a good Semantic Web handling of temperature such that QUDT need not implement things?

My best guess is that QUDT should work with temperature and probably is already the Semantic Web's go-to place for temperature quantity kinds, units etc. but that QUDT should not work to replicate Semantic Web spatiality, given the OGC and other's long-time work in the field. As Simon's noted above, perhaps QUDT can stick to scalar values?

Current work with GeoSPARQL 1.1 is introducing a SpatialMeasure class and right this week I'm working on examples of QUT scalar measurements using SpatialMeasure alongside GeoSPARQL Geometry examples which, hopefully, both QUDT and OGC people can comment on. GeoSPARQL 1.1 will be out for full public review shortly, so please do weigh in officially on that draft.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

dr-shorthair commented 3 years ago

@jhodgesatmb Which 'altitude' do you mean? The EPSG database (which is generally seen as the most up to date inventory of geodetic systems) has 220 distinct vertical reference systems.

dr-shorthair commented 3 years ago

[Altitude] is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind.

No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position.

jhodgesatmb commented 3 years ago

what are the units of altitude? I have only ever heard of it in ft, m, mi, km, ...

On Sun, Apr 18, 2021 at 1:42 AM Simon Cox @.***> wrote:

[Altitude] is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind.

No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qudt/qudt-public-repo/issues/379#issuecomment-821956097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQRWOVYWNZ6GC4LGPVLU3TJKLQJANCNFSM425HV4TA .

-- Jack

jhodgesatmb commented 3 years ago

I can see that length (size) and distance are different, so altitude is a distance. My mistake. Distance and length do have the same dimensionality. If I do a simple lookup in the dictionary or wikipedia (not authoritative sources but good enough for the point) I find several definitions, most notably differences between its use in aviation, atmospheric studies, and geometry. Given that QUDT originated with NASA I suspect Altitude is used in the aviation context. The question is twofold: (1) whether altitude is a quantity kind (and not whether it is ambiguous across domains), and (2) whether altitude should be represented in QUDT vocabularies. I see altitude as a quantity kind so to me it should be in the QUDT vocabulary of quantity kinds.

Wikipedia (a longish description but the first few paragraphs under aviation are):

In aviation, the term altitude can have several meanings, and is always qualified by explicitly adding a modifier (e.g. "true altitude"), or implicitly through the context of the communication. Parties exchanging altitude information must be clear which definition is being used.[2] https://en.wikipedia.org/wiki/Altitude#cite_note-AFM_51-40-2

Aviation altitude is measured using either mean sea level https://en.wikipedia.org/wiki/Mean_sea_level (MSL) or local ground level (above ground level, or AGL) as the reference datum.

Pressure altitude https://en.wikipedia.org/wiki/Pressure_altitude divided by 100 feet (30 m) is the flight level https://en.wikipedia.org/wiki/Flight_level, and is used above the transition altitude https://en.wikipedia.org/wiki/Transition_altitude (18,000 feet (5,500 m) in the US, but may be as low as 3,000 feet (910 m) in other jurisdictions); so when the altimeter reads 18,000 ft on the standard pressure setting the aircraft is said to be at "Flight level 180". When flying at a flight level, the altimeter is always set to standard pressure (29.92 inHg https://en.wikipedia.org/wiki/Inches_of_mercury or 1013.25 hPa https://en.wikipedia.org/wiki/Pascal_(unit)).

Merriam-Webster: 1a: the vertical elevation of an object above a surface (such as sea level or land) of a planet or natural satellite b: the angular elevation of a celestial object above the horizon c(1): a perpendicular https://www.merriam-webster.com/dictionary/perpendicular#h1 line segment from a vertex (see VERTEX sense 2a https://www.merriam-webster.com/dictionary/vertex) of a geometric figure (such as a triangle or a pyramid) to the opposite side or the opposite side extended or from a side or face to a parallel side or face or the side or face extended (2): the length of an altitude 2a: vertical distance or extent b: position at a heightThe plane lost altitude. c: an elevated region : EMINENCE https://www.merriam-webster.com/dictionary/eminence —usually used in plural 3: a high level (as of quality or feeling)the altitudes of his anger

On Sun, Apr 18, 2021 at 7:21 AM Jack Hodges @.***> wrote:

what are the units of altitude? I have only ever heard of it in ft, m, mi, km, ...

On Sun, Apr 18, 2021 at 1:42 AM Simon Cox @.***> wrote:

[Altitude] is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind.

No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qudt/qudt-public-repo/issues/379#issuecomment-821956097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATQRWOVYWNZ6GC4LGPVLU3TJKLQJANCNFSM425HV4TA .

-- Jack

-- Jack

ralphtq commented 3 years ago

Altitude is quantified with respect to a datum. Likewise depth below sea level. Perhaps these can be handled in a similar way to how coordinate systems are specified. In the NASA work QUDT defined 23 coordinate systems. They should be somewhere in the REPO. I remember not being done on coordinate systems because they lacked support for transformations.

Ralph Hodgson

On Apr 18, 2021, at 4:42 AM, Simon Cox @.***> wrote:

 [Altitude] is a specialization of height which is a specialization of distance which is a specialization of length which is a quantity kind.

No - Altitude or elevation is not a specialization of length. It is a measure of offset in a specified direction from a specified reference level, which in turn varies according to lateral position.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

steveraysteveray commented 3 years ago

In support of @jhodgesatmb's point about QUDT's goal of being inclusive, I'd suggest we keep Altitude in the vocabulary, with reference(s) to the OGC entities that correspond. Consistent with how we provide cross-references to other standards, we could invent a new property, something like qudt:ogcMatch (analogous to qudt:dbpediaMatch), or just use rdfs:seeAlso.

dr-shorthair commented 3 years ago

@jhodgesatmb You can think of altitude as a distance rather than a length, but distance is always measured from a location. For elevation or altitude this is in a specified direction from a reference level. The direction is vertical, i.e. parallel to the gravity vector, and measured positive upwards. The reference level or datum is usually a spheroid, defined by spherical harmonics (to order 300+), which is at different heights relative to the centre of the earth at different locations, to approximate 'the geoid', which is the surface corresponding to local sea-level.

But the main point here is that altitude or elevation is strictly not a quantity, it is a coordinate. It only feels like a simple quantity if you make assumptions about the reference level - probably 'mean sea level', and the direction - up (compare to 'down', which gives you depth rather than elevation/altitude). For many purposes that is 'good enough' but I don't think 'good enough' is the goal of QUDT. As I mentioned, the reference dataset for geodesy records more than 200 vertical reference systems in use around the world.

It is unhelpful to pretend it is simpler than that, particularly as there are recognised authorities for geodesy. (I don't accept the proposition that Wikipedia or the Merriam-Webster dictionary are a superior authority for geodetic concepts.)

dr-shorthair commented 3 years ago

And yes @steveraysteveray Celsius and Fahrenheit scales do not measure quantities, they measure position on a temperature scale. As @JoelBender points out, ThermodynamicTemperature (the Kelvin scale) is a quantity, while the more familiar Temperature is not.

VladimirAlexiev commented 3 years ago

@jhodgesatmb

VladimirAlexiev commented 3 years ago

@dr-shorthair @nicholascar could you please weigh in on https://github.com/gs1/EPCIS/issues/266 ?

dr-shorthair commented 3 years ago

I'm sure they cannot be converted using merely Factor+Offset

Definitely not, since they are location dependent.