rob-metalinkage
commented
6 years ago QB4ST[1] supports this Use Case as a metadata construct that would allow transparent delcaration of the nature of a temporal dimensions in a dataset. Another layer of metadata would be required to specify that a particular API uses that particular dimension in a specific query parameter,
Rob Atkinson
[1] https://w3c.github.io/sdw/qb4st/
On Fri, 24 Nov 2017 at 03:16 Chris Little notifications@github.com wrote:
This use case is really a requirement too. When statistical values are derived from quantities of interest (e.g. climatological mean wind velocity at a location for the month of October), there are a wide variety of time durations and instants that may be underpinning the statistics of interest.
When the RDF Data Cube was created by ISO/UN statistical experts from the SDMX standard, the only agreed 'sub-setting' mechanism was 'slice' across a dimension. Successive or simultaneous slicing along all the dimensions will allow single values to be extracted from the data cube. I understand that there was further work on reporting periods for aggregating the values over weeks, months, quarters, years, etc., but the work was not successfully concluded.
Time is notoriously complicated. As St Augustine said about 400CE "Si nemo ex me quaerat, scio; si quaerente explicare velim, nescio" [ "If no one asks me, I know what it is. If I wish to explain it to him who asks, I do not know."] Confessions, Chap XI, Book 14. The complications are because of calendars, which try to put random periods of rotation of astronomical bodies into useful and understandable patterns. And software that tries to do this is prone to errors too, as the algorithms are heuristic and imprecise rather than mathematical.
The standard calendar is the Gregorian, which incorporates leap days almost every 4 years, and also leap seconds as specified by the IERS in Paris. This calendar, and instants and durations can be reasoned about using the W3C Recommendation: Time Ontology in OWL, https://www.w3.org/TR/owl-time/ and this can also be used as a basis for constructing other calendars.
OGC has a registry of temporal Coordinate Reference Systems, which are more tractable than calendars, such Julian Day Number (days and fractions of days since noon on Monday, January 1, 4713 BCE), Unix time (milliseconds since midnight, 1 Jan 1970), and International Atomic Time (TAI).
This 'use case' is proposing that some consistent and rigorous structures be built that will allow the construction of a wide variety of durations or periods , relating to a variety of calendar or temporal CRSs for aggregation of statistics.
Example: climatology for a location and a parameter of interest is usually constructed using 30 year periods of yearly, monthly, daily, hourly or even more frequent data. A user may be interested in the climatological mean daily temperature for January, or the maximum daily minimum temperature for the European winter months of Dec, Jan and Feb.
How can such descriptive metadata be constructed for use in a wide variety of domains, and allow rigorous reasoning about the values of interest?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/sdw/issues/981, or mute the thread https://github.com/notifications/unsubscribe-auth/AIR3YREW-2PyVi8wbmNGHEBagvMqIEzsks5s5X4ggaJpZM4Qo0c5 .
This use case is really a requirement too. When statistical values are derived from quantities of interest (e.g. climatological mean wind velocity at a location for the month of October), there are a wide variety of time durations and instants that may be underpinning the statistics of interest.
When the RDF Data Cube was created by ISO/UN statistical experts from the SDMX standard, the only agreed 'sub-setting' mechanism was 'slice' across a dimension. Successive or simultaneous slicing along all the dimensions will allow single values to be extracted from the data cube. I understand that there was further work on reporting periods for aggregating the values over weeks, months, quarters, years, etc., but the work was not successfully concluded.
Time is notoriously complicated. As St Augustine said about 400CE "Si nemo ex me quaerat, scio; si quaerente explicare velim, nescio" [ "If no one asks me, I know what it is. If I wish to explain it to him who asks, I do not know."] Confessions, Chap XI, Book 14. The complications are because of calendars, which try to put random periods of rotation of astronomical bodies into useful and understandable patterns. And software that tries to do this is prone to errors too, as the algorithms are heuristic and imprecise rather than mathematical.
The standard calendar is the Gregorian, which incorporates leap days almost every 4 years, and also leap seconds as specified by the IERS in Paris. This calendar, and instants and durations can be reasoned about using the W3C Recommendation: Time Ontology in OWL, https://www.w3.org/TR/owl-time/ and this can also be used as a basis for constructing other calendars.
OGC has a registry of temporal Coordinate Reference Systems, which are more tractable than calendars, such Julian Day Number (days and fractions of days since noon on Monday, January 1, 4713 BCE), Unix time (milliseconds since midnight, 1 Jan 1970), and International Atomic Time (TAI).
This 'use case' is proposing that some consistent and rigorous structures be built that will allow the construction of a wide variety of durations or periods , relating to a variety of calendar or temporal CRSs for aggregation of statistics.
Example: climatology for a location and a parameter of interest is usually constructed using 30 year periods of yearly, monthly, daily, hourly or even more frequent data. A user may be interested in the climatological mean daily temperature for January, or the maximum daily minimum temperature for the European winter months of Dec, Jan and Feb.
How can such descriptive metadata be constructed for use in a wide variety of domains, and allow rigorous reasoning about the values of interest?