ISSUE-141: Requirements for specific duration classes or individuals
Requirements for specific duration classes or individuals
- State:
- CLOSED
- Product:
- Time ontology in OWL
- Raised by:
- Simon Cox
- Opened on:
- 2017-01-20
- Description:
- We need some clarification of the requirements for resources for the standard durations :Year, :Month, ... :Second . There are at least four ways to build these:
1. subclass of :DurationDescription, fixing the value of :years to 1, and the cardinality of :months, :weeks, ... :seconds to 0
2. subclass of :Duration, fixing the value of :unitType to :unitYear, and the value of :numericDuration to 1
3. both the above
4. individual :DurationDescription, with the value of :years set to 1, and all other duration description properties set to 0
5. individual :Duration, with the value of :unitType set to :unitYear, and the value of :numericDuration set to 1
6. both the above
7. all four.
Option 1. is close to what Hobbs and Pan did in the 2006 version, except that they did not fix the value of :years, only the cardinality. I'm a little confused about this since it appears to define a class of which individual members where the value of :years can be any number. If that was indeed the intention, then it would better be called :Years. OTOH, if the intention is to just have a class representing the concept 'one year duration' then the value must be set as well, as I propose here.
Rinse and repeat for :Month, :Week, :Day, :Hour, :Minute, :Second
In order to move forward, we need to understand the actual requirements, which I think are from the QB4ST team (RobA, Kerry).
- Related Actions Items:
- No related actions
- Related emails:
- RE: OWL-Time - Individual months, standard temporal durations (from Simon.Cox@csiro.au on 2017-02-26)
- RE: OWL-Time - Individual months, standard temporal durations (from Simon.Cox@csiro.au on 2017-02-20)
- OWL-Time - Individual months, standard temporal durations (from Simon.Cox@csiro.au on 2017-02-12)
- Re: ISSUE-142: January-December - classes or individuals (from rob@metalinkage.com.au on 2017-02-09)
- ISSUE-142: January-December - classes or individuals (from Simon.Cox@csiro.au on 2017-02-09)
- Issues concerning Year etc, and January-December (from Simon.Cox@csiro.au on 2017-01-22)
- RE: ISSUE-124 - deprecate January and Year (from Simon.Cox@csiro.au on 2017-01-20)
- RE: ISSUE-124 - deprecate January and Year (from Simon.Cox@csiro.au on 2017-01-20)
Related notes:
The requirements come from the higher level requirements (provide metadata and re-use vocabularies) and the common practice of including time information in data. The specific Use Case that QB4ST should exercise is to describe a hierarchical time dimension - where a "data cube" is based on a time concept - lets say traffic flow at a junction recorded every second, but the data may be sliced by day, month and year, or "rolled-up" - for example average flow per hour per day of week. QB4ST probably needs mainly classes, whereas expressing the data in RDF will require canonical versions of individual instances. QB4ST potentially allows us to attach metadata to those instances - for example to record the time-zone or resolution of each value.
What would be useful is for the Time ontology to provide subclasses for typical Gregorian Calendar entities and how these should be related in the class model, and instances (i.e. is there such a thing as "January" or is it "January 2007 in UTC+3" - and how one might assert that a resource with the value "January" is in fact an instance of months based on UTC+3 TZ.
Display change log
