ISSUE-180: Integer time quantities and positions
Integer time quantities and positions
- State:
- CLOSED
- Product:
- Time ontology in OWL
- Raised by:
- Simon Cox
- Opened on:
- 2017-04-21
- Description:
- Mark Hedley (UK Met Office) raised this issue in a email on 2017-03-23:
The issue we are working towards for ISO19111 is enabling the use of either TemporalMeasure (continuous, decimal) and TemporalCount (integer
only)
We are aiming to differentiate between these, and limit scope by enforcing a choice of one or other for an individual Coordinate Reference System instance.
In order to share terminology with OWL:Time, I would like to define a time duration constrained to an integer quantity
At present, the
https://www.w3.org/TR/owl-time/#time:hour
is described as
'Hour position in a calendar-clock system'
and is constrained to
https://www.w3.org/TR/xmlschema11-2/#nonNegativeInteger
whilst
https://www.w3.org/TR/owl-time/#time:hours
is described as
'length of a temporal extent expressed in hours'
and is constrained to
https://www.w3.org/TR/owl-time/#time:Number
providing
'Equivalent class: xsd:double or xsd:float or xsd:decimal'
My use case is:
define a temporal count quanity such that my coordinates are offsets
of this quantity from a defined temporalDatum
I think this is a 'length extent expressed in ...' in owl:time speak However, I cannot store an integer in this.
I wonder whether it would be possible to add a new type, a sub-type of https://www.w3.org/TR/owl-time/#time:Number
Count
RDFS Class: time:Count
Definition: Generalized integer number
Instance of: time:Number
Equivalent class: xsd:integer
Obviously I'm happy to discuss any options.
I do wonder whether this represents a small additive change that might neatly allow my use case I would really value your thoughts on this. - Related Actions Items:
- No related actions
- Related emails:
- No related emails
Related notes:
Simon responded on 2017-03-27
1. Be careful. OWL-Time has a lot of rdfs:domain axioms on the properties, so the entailments are pretty strong any time you use them.
2. time:hours is for amounts or temporal extents (i.e. durations), while time:hour is for temporal position, offset from an origin within a TRS.
These are globally constrained to be associated with an instance of time:GeneralDurationDescription or time:GeneralDateTimeDescription, respectively.
Of course time:hour(s) sits alongside year(s), month(s), week(s), day(s), minute(s) and second(s) for when you choose to express the duration or position using a clock/calendar, instead of a single unit-of-measure*.
If you want a class that is limited to integer values of just one of these quanta then you have to suppress the other quantizations.
You can do that by defining a sub-class of either time:DateTImeDescription (for positions) or time:DurationDescription (for extents).
First you force the :hours property to be an integer (note different namespace "itime:") -
itime:hours
rdf:type owl:DatatypeProperty ;
rdfs:range xsd:integer ;
rdfs:subPropertyOf time:hours ;
.
Then you restrict the cardinalities of the properties of the class, so that only the (restricted version of ) :hours is expected -
itime:Hours
rdf:type owl:Class ;
rdfs:subClassOf time:DurationDescription ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:cardinality "1"^^xsd:nonNegativeInteger ;
owl:onProperty itime:hours ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:days ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:minutes ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:months ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:seconds ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:weeks ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:maxCardinality "0"^^xsd:nonNegativeInteger ;
owl:onProperty time:years ;
] ;
.
This option (only allowing one of the ticks) is close to the model for time:Year from the original OWL-Time (should have been time:Years since it is a duration not position :-( ), but we decided to deprecate that in the new version. Rinse and repeat for itime:Hour, as a subclass of time:DateTimeDescription.
Alternatively, and probably easier, you can start with time:Duration (which is just a number with a single scale) or time:TimePosition (ditto) and restrict the value of time:unitType instead, like this.
itime:HoursDuration
rdf:type owl:Class ;
rdfs:subClassOf time:Duration ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:allValuesFrom xsd:integer ;
owl:onProperty time:numericDuration ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:hasValue time:unitHour ;
owl:onProperty time:unitType ;
] ;
.
itime:HourPosition
rdf:type owl:Class ;
rdfs:subClassOf time:TimePosition ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:allValuesFrom xsd:integer ;
owl:onProperty time:numericPosition ;
] ;
rdfs:subClassOf [
rdf:type owl:Restriction ;
owl:hasValue time:unitHour ;
owl:onProperty time:unitType ;
] ;
.
OK?
Simon
Mark seemed happy with the response - email 2017-04-07
Hello Simon
thanks again for the insights
my interpretation is that I do not need to request any changes to OWL time and that for my use cases the use of time:hour to describe a position as described by a temporal count coordinate
I think the constraint mechanism makes sense, if i think about it carefully
many thanks for the input and insight
mark
Display change log
