Re: ISSUE-124 - deprecate January and Year

point taken (sharp stick removed from eye...)

i was really focussed on identification of what is being used - and i guess
i see calendars like spatial features - you can declare a topology between
hierarchies and neighbours - but you wouldnt want to rely on spatial
operations on approximated boundaries to develop those relationships on the
fly, even if it were computationally reasonable.

a system can thus keep data in temporal reference system using numbers, but
expose it via a hierarchical dimension - years, months etc and its up to
the system how it implements it. The role of QB4ST is to allow those units
that are supported to be identified, not to define or support operations.

Having some really tight use cases ( and i havent worked out how to use the
other cases you sent) that handles a couple of contrasting examples would
help.  I'm happy to keep trying to work something up - but i'd like to
start with showing how to be more explicit about the existing qb examples -
then show a compelling case for the more generalised case. For example
being able to determine that data based on UK financial years is similar in
granularity to one base on US years (i.e. is a time dimension with months
as a hierarchy level) but is also different,  gets us to a useful point
beyond simply putting a name "years" in a label or minting our own URI for
each time we need a definition of years.

Rob

On Fri, 23 Dec 2016 at 01:26 Little, Chris <chris.little@metoffice.gov.uk>
wrote:

> 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> 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]
> *Sent:* Thursday, 22 December, 2016 12:44
> *To:* Rob Atkinson <rob@metalinkage.com.au>; Cox, Simon (L&W, Clayton) <
> Simon.Cox@csiro.au>; 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
> <rob@metalinkage.com.au>]
> *Sent:* Wednesday, 21 December 2016 7:38 PM
> *To:* Simon.Cox@csiro.au; 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> 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 *T* +61 3 9545 2365 <(03)%209545%202365> *M* +61
> 403 302 672 <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
>
> orcid.org/0000-0002-3884-3420
>
> researchgate.net/profile/Simon_Cox3
> <https://www.researchgate.net/profile/Simon_Cox3>
>
> 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.*
>
>
>
>
>
>