RE: ISSUE-124 - deprecate January and Year

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]
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.