New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StatsBP Use Case: Temporal constructs #981
Labels
Projects
Comments
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 ***@***.***> 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
<#981>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIR3YREW-2PyVi8wbmNGHEBagvMqIEzsks5s5X4ggaJpZM4Qo0c5>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
The text was updated successfully, but these errors were encountered: