RE: ISSUE-124 - deprecate January and Year

Hi Rob,

I hope you are not falling into the quagmire of using calendars as coordinates?

The one thing, if perhaps the only thing, that I have learnt in the last few years is that a CRS for time should have a single UoM, and values on the coordinate axis can be expressed as integers or reals of that unit.

Anything that adds extra units, periods/cycles, etc is a calendar and is messy. I think that is why the original ISO SMDX extensions to QB never got anywhere – they spent all their time on weeks, months, days, years trying to generalise reporting periods and all that stuff statisticians and accountants do with spreadsheets.

Simon has very carefully allowed the distinction in the revised OWL-Time, so people can specify decimal years, or decimal weeks or days or seconds etc . What does a spreadsheet actually do in practice? It converts calendar notations into milliseconds since 1970-01-01T00:00:00.000, a CRS, performs the duration and summary calculations, then converts back to the calendar notations.

I think that there are too many schemas that try to pretend that calendar entities, such as xsdL:dateTime, etc, are CRSs when they are a different kettle of fish (sorry about the mixed metaphors – not enough mince pies;-)

Obviously, the SI prefixes and multiples are acceptable as scale modifiers of as UoM, but the calendar cycles of 28/29/30/31, 28/4*7, 19/19, 365/366, 28/7*4, etc are fundamentally just numerology (that is meant to be rude about numerology – apologies if you find it fun).

I hope you can keep these clearly distinct use cases separate, and not smear over that semantic boundary. Of course, we are starting in the wrong place to get to where we want to go, but c’est la vie!

Chris

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Thursday, December 22, 2016 7:05 AM
To: Simon.Cox@csiro.au; kerry.taylor@anu.edu.au; rob@metalinkage.com.au; public-sdw-wg@w3.org
Subject: Re: ISSUE-124 - deprecate January and Year

I suspect instances makes more sense - unless there really are many flavours of January ? But the same holds true for Days.

What we need for QB4ST (and i havent bottomed out the most elegant option) is to be able to express that a dimension is hierarchical, and can be addressed with Year or Month granularity, and a particular dataset has a range (in the coverage sense) of a span of years. And then be able to repeat that pattern to show a dataset for a coverage of 2016 is addressible by month, year, day and has a range of say April-October.

Finally an example of financial yea might be helpful in navigeting the model; - lets say Austrailia July 1 - June 30 vs UK April X (https://www.taxadvisorypartnership.com/tax-compliance/why-does-the-uk-tax-year-start-on-6-april-each-year/)
QB4ST would ideally allow people to be specific about what they have, allow subsumption reasoning -(oh that wierd thing is a dataset with a Time dimension that contains data for calendar months!) - and also allow for normalised extent metadata - and QB4ST is the place where "normal" is defined.

Expression of the conversions necessary to integrate data is beyond scope, but identification of the necessary conversion i think should be supported by looking at the rdfs:range of qb:Components (Time classes)  - and maybe conversions can be supported through reasoning over the Time model and the attributes of the instances of Time classes?


NB The pattern of Class-skos:Concept duality still allows me to think of a Class January as a Concept instance - so i dont see using Class as a show-stopper - this Convep ontology is just another graph that can be auto-generated - doing this with SPIN insdie the triple store in my registry experiments.

Rob

On Thu, 22 Dec 2016 at 15:07 <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
What do you need for QB4ST?
Is it the set of classes

-          Year, Month, Week, Day, Hour, Minute, Second

o   subclasses of DurationDescription

-          January, February … December

o   Subclasses of DateTimeDescription

That would be easy to generate, though I think we should take care of some multi-lingual labelling.

However, this treatment of the months would be inconsistent with the way that DayOfWeek is handled:

-          Monday, Tuesday … Sunday

o   *instances* of DayOfWeek

To be consistent with the latter pattern we should define a class MonthOfYear and make the individual months as individuals from that class.

Which pattern is preferred?

Simon

From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>]
Sent: Thursday, 22 December, 2016 12:44
To: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ISSUE-124 - deprecate January and Year

This makes sense – I agree -  --- will make owl-time more usable.  Put it in a separate namespace and make it non-normative makes is both a useful example for owl-time, a useful ontology on its own that makes Time more readily useable, and also serves  QB4ST .

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, 21 December 2016 7:38 PM
To: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: Re: ISSUE-124 - deprecate January and Year

Cant we deprecate 2016 ?

seriously though, i think this proposal makes sense - but it would also be useful to have a new namespace - where such things are defined - that both makes Time relevant to the vast majority of users who just need the common cases, and provides a useful example of how a community uses Time to define its specialised flavours. Either an adjunct graph defining these or a strong statement that a register of re-usable Time specialisations is needed to implement the Time _model_ - i,e, its not a Time ontology at all, but a Time Model ontology...

QB4ST is looking to provide examples of Time in dimension specification - and the one i really need is to be able to define a dimension that is a hierarchy of years and months - currrently i'd need to make up the intermediate layer in some non-canonical namespace and that feels wrong on many levels.

 (Note also QB4ST is designed as the object model for a registry of community defmined diensions that can be reused - probably a similar pattern applies to Time - but having this most basic case as an ontology doesnt preclude that being used to seed such a registry)


Rob Atkinson


On Wed, 21 Dec 2016 at 18:02 <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
Great subject eh?

This related to two classes defined in the 2006 version of OWL-Time, which are really just examples so should never have been in the main namespace. Propose to mark them deprecated. Raised it a couple of times. I don’t think there is any controversy here, so will just close the issue.

Simon

Simon J D Cox
Research Scientist
Environmental Informatics
CSIRO Land and Water<http://www.csiro.au/Research/LWF>

E simon.cox@csiro.au<mailto:simon.cox@csiro.au> T +61 3 9545 2365<tel:(03)%209545%202365> M +61 403 302 672<tel:0403%20302%20672>
   Mail: Private Bag 10, Clayton South, Vic 3169
   Visit: Central Reception, Research Way, Clayton, Vic 3168
   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
people.csiro.au/Simon-Cox<http://people.csiro.au/Simon-Cox>
orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420>
researchgate.net/profile/Simon_Cox3<https://www.researchgate.net/profile/Simon_Cox3>
github.com/dr-shorthair<https://github.com/dr-shorthair>

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.