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