RE: ISSUE-124 - deprecate January and Year

I’ve moved both [January … December] and [Year … Second] into (proposed) new namespace<>
- see

though not confident that [Year … Second] are actually Gregorian concepts …
If not, they should revert to the main namespace.
If they are, then possibly should also move [unitYear … unitSecond] as well.

Also there is [Monday … Sunday] (individuals) from the original ontology, but I don’t think that days-of-week are Gregorian concepts?
But maybe they should be in yetanother namespace?


From: Rob Atkinson []
Sent: Tuesday, 10 January, 2017 09:09
To: Cox, Simon (L&W, Clayton) <>;;
Subject: Re: ISSUE-124 - deprecate January and Year

Thanks Simon
on the road on a family holiday and not fully brain-in-gear yet.. but will attempt to put together some thoughts on the fairly obvious Use Case i want to try out - creating hierarchical time dimensions for datacubes - one based on calendars (describing that a dataset has properties year and month, and that year+month is the composite dimension, but that the dataset is also sliceable by year in a particular range)  and one on eras (historical or geological)

I'm still not that comfortable mixing the instances and the models in a single ontology resource - the question is whether some key subclasses should be in OWL-Time, or a canonical GregorianCalendar.owl ontology that uses it as a model and illustrates how to use OWL-Time for specialised cases?


On Mon, 9 Jan 2017 at 14:29 <<>> wrote:

1)     Yes. What I did in this proposal was merely to chase through the patterns already existing in the 2006 Ontology.

a.     Old OWL-Time had (only) Year and (only) January each as sub-classes (restrictions of DurationDescription and DateTimeDescription, respectively). I initially proposed deprecation, but you and Kerry suggested completing the sets instead, to support some requirements from QB4ST. So I did that to see what it looked like, following exactly the patterns from the 2006 version.  Net result: Month, Week, Day … Second all modelled as classes, as well as February, March … December also modelled as classes.

b.     However, Old OWL-Time also had a class DayOfWeek, with [Monday … Sunday] as individual members. This looks like an alternative precedent for the months, modelled as individuals. So I also implemented a new class MonthOfYear, with [January … December] as individual members.

Hence, merely by following the precedents from the 2006 version, we get the standard durations (including ‘Month’) modelled as classes, and individual months (January, February …) modelled as *both* classes and individuals. Which do you prefer? And what do you suggest we do to make the whole thing consistent? Or is that too much to expect?

2)     “month” property is just copied through from the 2006 Ontology (though the documentation is more explicit).
The notation “--04” is from xsd:gMonth – see .

“nominalPosition” is new in this version of the ontology, and was introduced to support named time positions, which are used in geology, archeology etc, but might also be useful in other contexts. Use of nominalPosition requires a reference system which is a list of named times which have *absolute* ordering relationships. OTOH month values are only ordered in the context of a specified year.


From: Rob Atkinson [<>]
Sent: Tuesday, 3 January, 2017 04:13
To: Cox, Simon (L&W, Clayton) <<>>;<>
Subject: Re: ISSUE-124 - deprecate January and Year

Hi Simon
sorry to take so long to get back to this - not enough sober opportunities to do it justice over christmas :-)

Only one voice here - but maybe just iterate an issue at a time...

the first couple of things I am wondering about are:
1) the ontology seems to mix classes an instances at different levels of abstraction - which is IMHO a difference issue than instance/subclass duality :Month is modelled Class, but :January is an instance.  (i dont have the right leanguage for this but "real Instances" are bound to literal values, as opposed to classes being instances of the Class concept.). I guess the question is whether the concept of Month and Year are specialisations of Interval that deserve to be in the main Time ontology.
2) the "month" property feels a bit odd still..

  rdf:type owl:DatatypeProperty ;

  rdfs:comment """Month position in a calendar-clock system.

The range of this property is not specified, so can be replaced by any specific representation of a calendar month from any calendar. """@en ;

  rdfs:domain :GeneralDateTimeDescription ;

  rdfs:label "month"@en ;

this feels like it is perhaps a subPropertyof :nominalPosition -
and these all feel like models of time concepts - not a set of instances

whats the rationale and documentation for the range in this form "--04"  ?

I think if i had a better handle on these I'd be able to look deeper into it.


On Thu, 29 Dec 2016 at 06:17 <<>> wrote:
As I've been working on two separate groups of issues in OWL-Time, I've created two branches with names to reflect these. So the work described below which was initially in a branch simon-time is now in simon-time-individuals

-----Original Message-----
From: Cox, Simon (L&W, Clayton)
Sent: Wednesday, 28 December, 2016 08:01
To: 'Rob Atkinson' <<>>; Little, Chris <<>>;<>;<>
Subject: RE: ISSUE-124 - deprecate January and Year

OK – so take a look in the RDF file for OWL-Time in the branch simon-time [1]

Following the examples of January and Year from 2006 OWL-Time, I've created resources for 1. all of the months-of-the-year as subclasses of DateTimeDescription 2. all of the basic time durations as subclasses of DurationDescription

I've also

3. shown how Year, Month, Week ... etc can also be conceived as subclasses of the new class Duration, for example

  rdfs:subClassOf :Duration ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:hasValue :unitYear ;
      owl:onProperty :unitType ;
    ] ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:hasValue 1 ;
      owl:onProperty :numericDuration ;
    ] ;

In addition to the original subclassing from DurationDescription.

4. shown how January, February, March ... etc can be conceived as individuals from a new class MonthOfYear, which follows the precedent of DayOfWeek which was already there. So for example, the complete description of April looks like

  rdf:type owl:Class ;
  rdf:type :MonthOfYear ;
  rdfs:label "April"@en ;
  rdfs:subClassOf :DateTimeDescription ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:hasValue :unitMonth ;
      owl:onProperty :unitType ;
    ] ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:hasValue "--04" ;
      owl:onProperty :month ;
    ] ;
  skos:prefLabel " ?@5;L"@ru ;
  skos:prefLabel "#(1JD"@ar ;
  skos:prefLabel "4 "@ja ;
  skos:prefLabel "4 "@zh ;
  skos:prefLabel "Abril"@es ;
  skos:prefLabel "Abril"@pt ;
  skos:prefLabel "April"@de ;
  skos:prefLabel "April"@en ;
  skos:prefLabel "April"@nl ;
  skos:prefLabel "Aprile"@it ;
  skos:prefLabel "Avril"@fr ;
  skos:prefLabel "KwiecieD"@pl ;

So each month is both a class and an individual.
Note that I also added multi-lingual labelling for months and days, scraped from DBPedia, using the skos:prefLabel annotation.

5. In the branch these are all in the main namespace.

So there are a few questions here:
(i) Should months be both classes (following the precedent from 2006) and individuals (following the pattern from DayOfWeek)
(ii) Should the duration individuals be both DurationDescription and Duration (don't see why not)
(iii) what namespace for all these
(iv) what property to be used for multi-lingual labels



Received on Wednesday, 11 January 2017 06:14:51 UTC