Copyright
©
2016
2017
OGC
&
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
W3C
liability
,
trademark
and
document
use
rules
apply.
The
OWL-Time
ontology
is
an
OWL-2
DL
ontology
[
owl2-direct-semantics
]
of
temporal
concepts,
for
describing
the
temporal
properties
of
resources
in
the
world
or
described
in
Web
pages.
The
ontology
provides
a
vocabulary
for
expressing
facts
about
topological
relations
among
instants
and
intervals,
together
with
information
about
durations,
and
about
temporal
position
including
date-time
information.
The
namespace
for
OWL-Time
terms
is
http://www.w3.org/2006/time#
The
suggested
prefix
for
the
OWL-Time
namespace
is
time
The
(revised)
OWL-Time
ontology
itself
is
available
here.
here
.
The
original
OWL-Time
ontology
is
still
available
there.
Note
The
original
namespace
(http://www.w3.org/2006/time)
remains
and
will
remain
valid.
Terms
in
the
original
namespace
may
be
deprecated
by
future
versions
of
this
document
but
will
not
be
deleted.
This
policy
will
hold
when
the
revised
ontology
is
merged
with
the
original,
later
in
the
standardization
process.
This
initial
publication
is
designed
to
solicit
comments
on
this
and
all
aspects
of
the
current
work.
there
.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
https://www.w3.org/TR/.
This
is
the
first
version
of
the
Time
Ontology
in
OWL
to
be
developed
by
the
Spatial
Data
on
the
Web
Working
Group,
a
joint
activity
of
W3C
and
OGC
.
It
builds
on
the
original
work
done
in
2006
by
the
(now
closed)
Semantic
Web
Best
Practices
and
Deployment
Working
Group
,
edited
by
Jerry
Hobbs
and
Feng
Pan.
For
OGC
This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group ( SDWWG ) — a joint W3C -OGC project (see charter ). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.
This document was published by the Spatial Data on the Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-sdw-comments@w3.org ( subscribe , archives ). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 1 September 2015 W3C Process Document .
Temporal
information
is
so
common
that
it’s
hard
to
find
a
real
world
Web
service
without
it.
For
example,
whenever
you
place
an
online
order,
the
order
date
is
always
part
of
your
order.
When
you
reserve
a
car
at
a
car
rental
site,
you
have
to
specify
the
dates
you
need
it.
In
response
to
this
need,
a
temporal
ontology,
OWL-Time,
has
been
developed
for
describing
the
temporal
content
of
Web
pages,
or
the
temporal
properties
of
any
resource
denoted
using
a
web
identifier
(URI),
including
real-world
things
if
desired.
desired.
This document presents the OWL encodings of the ontology. For a first-order logic axiomatization of the ontology, see [ HP-04 ].
This
version
of
OWL-Time
was
developed
in
the
Spatial
Data
on
the
Web
Working
Group
(a
joint
activity
involving
W3C
and
the
Open
Geospatial
Consortium).
It
The
ontology
is
based
on
the
earlier
draft
by
Hobbs
and
Pan,
[
owl-time-20060927
OWL-T
]
with
incorporating
modifications
proposed
by
Cox,
Cox
[
CO-16
CO-15
]
to
support
more
general
temporal
positions.
Specifically:
GeneralDateTimeDescription
and
GeneralDurationDescription
generalize
the
corresponding
classes
from
the
draft,
for
cases
which
the
temporal
reference
system
is
not
fixed
to
the
Gregorian
Calendar
in
advance
TimePosition
and
Duration
enable
position
or
duration
to
be
described
using
a
number
or
nominal
value
the
property
hasTRS
enables
time
values
to
be
associated
with
a
temporal
reference
system,
represented
by
the
'stub'
class
TRS
A
number
of
requirements
relating
to
Time
were
identified
in
the
Spatial
Data
on
the
Web
Use
Cases
&
Requirements
.
5.7
Date,
time
and
duration
5.53
Update
datatypes
in
OWL
Time
5.9
Different
time
models
5.48
Temporal
reference
system
5.28
Nominal
temporal
references
5.56
Valid
time
5.49
Temporal
vagueness
5.51
Time
series
5.39
Space-time
multi-scale
5.22
4D
model
of
space-time
5.32
Provenance
5.25
Multilingual
support
Notes
are
included
to
indicate
where
these
have
been
addressed,
or
where
they
should
be
addressed.
Issue
1
https://www.w3.org/2015/spatial/track/issues/64
Most
of
the
properties
defined
in
the
original
ontology
have
global
constraints
on
the
domain
and
range.
If
the
rdfs:domain
were
left
unspecified,
the
properties
could
be
used
more
widely
without
undesirable
entailments.
Their
use
in
the
context
of
the
classes
in
the
ontology
is
adequately
controlled
through
guarded
restrictions
(local
cardinality
constraints)
Issue
2
https://www.w3.org/2015/spatial/track/issues/65
The
Time
ontology
is
concerned
only
with
formalizing
temporal
intervals
and
instants,
and
does
not
include
any
predicates
to
tie
temporal
objects
to
spatial
entities
or
features,
or
other
things.
The
editors
note
that
predicates
that
concern
temporal
behaviour
and
properties
will
usually
be
part
of
an
application
or
associated
with
a
community
of
practice.
Nevertheless,
there
may
be
some
generic
predicates
that
could
be
conveniently
provided
as
part
of
the
generic
time
ontology.
Some
may
already
exist
in
the
ontology
(
before
,
after
,
hasEnd
,
hasBeginning
)
but
their
rdfs:domain
is
:TemporalEntity
,
so
this
would
need
to
be
generalized
to
avoid
inappropriate
entailments.
Else
predicates
with
similar
names
could
be
provided
for
linking
to
other
entities.
Note
The
SDWWG
requirement
5.56
Valid
time
relates
to
https://www.w3.org/2015/spatial/track/issues/65
.
Issue
3
https://www.w3.org/2015/spatial/track/issues/26
Temporal
vagueness
requirement.
Extended
Data/Time
Format
(EDTF)
is
a
detailed
proposal
for
how
to
encode
temporal
vagueness,
and
some
other
concerns,
by
extending
the
xsd:dateTime
syntax
.
document
has
been
completely
re-written.
The
editors
consider
that
would
be
the
wrong
direction
since
it
would
make
the
encoding
inconsistent
with
all
XSD-based
processors.
On
the
other
hand,
specific
RDF
properties
matching
the
ones
proposed
in
EDTF
could
be
used
to
make
it
amenable
to
RDF
reasoning.
However,
we
should
consider
doing
this
in
a
separate
namespace.
Note
that
some
of
the
concerns
in
EDTF
substantial
changes
are
already
accommodated
listed
in
OWL-Time
(e.g.
'unspecified'
appears
to
only
require
the
timeUnit
to
be
chosen
appropriately).
Note
The
SDWWG
requirement
5.49
Temporal
vagueness
relates
to
https://www.w3.org/2015/spatial/track/issues/26
change-log
.
The
namespace
for
OWL-Time
is
http://www.w3.org/2006/time#
.
OWL-Time
does
not
re-use
elements
from
any
other
vocabularies,
but
does
use
some
built-in
datatypes
from
OWL
and
some
additional
types
from
XML
Schema
Part
2.
The table below indicates the full list of namespaces and prefixes used in this document.
Prefix | Namespace |
---|---|
ex
|
http://example.org/time/
|
geol
|
http://example.org/geologic/
|
owl
|
http://www.w3.org/2002/07/owl#
|
rdf
|
http://www.w3.org/1999/02/22-rdf-syntax-ns#
|
rdfs
|
http://www.w3.org/2000/01/rdf-schema#
|
time
or
no
prefix
|
http://www.w3.org/2006/time#
|
|
http://www.w3.org/2001/XMLSchema#
|
This section is non-normative.
The
basic
structure
of
the
ontology
is
based
on
an
algebra
of
binary
relations
on
intervals
(e.g.,
meets,
overlaps)
developed
by
Allen
and
Ferguson
[
AL-84
],
[
,
AF-97
]
for
representing
qualitative
temporal
information,
and
to
address
the
problem
of
reasoning
about
such
information.
This
is
implemented
in
the
ontology
starting
with
a
class
which
has
properties
that
link
to
the
temporal
instants
that
define
its
beginning
and
end.
There
are
two
subclasses:
TemporalEntity
:TemporalEntity
and
Interval
:Interval
,
and
they
are
the
only
two
subclasses
of
Instant
:Instant
.
Intervals
are,
intuitively,
things
with
extent
and
instants
are,
intuitively,
point-like
in
that
they
have
no
interior
points,
but
it
is
generally
safe
to
think
of
an
instant
as
an
interval
with
zero
length,
where
the
beginning
and
end
are
the
same.
The
class
TemporalEntity
:TemporalEntity
has
one
subclass
Interval
:Interval
,
which
corresponds
with
the
common
understanding
of
intervals,
in
that
the
beginning
and
end
are
distinct,
and
whose
membership
is
therefore
disjoint
from
ProperInterval
:ProperInterval
.
The
class
Instant
:Instant
has
one
subclass,
ProperInterval
:ProperInterval
,
whose
position
and
extent
may
be
expressed
using
a
single
DateTimeInterval
:DateTimeInterval
or
GeneralDateTimeDescription
:GeneralDateTimeDescription
.
xsd:dateTime
xsd:dateTimeStamp
Allen
and
Ferguson
[
AL-84
],
[
,
AF-97
]
have
developed
a
calculus
of
binary
relations
on
intervals
(e.g.,
meets,
overlaps)
for
representing
qualitative
temporal
information
and
address
the
problem
of
reasoning
about
such
information.
The
relations
between
intervals
defined
in
their
calculus
can
be
defined
in
a
relatively
straightforward
fashion
in
terms
of
and
identity
on
the
beginning
and
end
points.
The
standard
interval
calculus
assumes
all
intervals
are
proper,
whose
beginning
and
end
are
different.
before
:before
The
position
of
an
Instant
may
be
given
using
the
datatype
(or
one
of
the
truncated
forms
xsd:dateTime
xsd:dateTimeStamp
xsd:date
,
xsd:gYearMonth
,
xsd:gYear
)
which
is
built
in
to
OWL
2
[
owl2-quick-reference
OWL-2
],
and
uses
the
conventional
Gregorian
calendar
and
24-hour
clock.
While
this
satisfies
most
web
applications,
many
other
calendars
and
temporal
reference
systems
are
used
in
particular
cultural
and
scholarly
contexts.
For
example,
the
Julian
calendar
was
used
throughout
Europe
until
the
16
th
century,
and
is
still
used
for
computing
key
dates
in
some
orthodox
Christian
communities.
Lunisolar
(e.g.
Hebrew)
and
lunar
(e.g.
Islamic)
calendars
are
currently
in
use
in
some
communities,
and
many
similar
have
been
used
historically.
In
scientific
and
technical
applications,
Julian
date
counts
the
number
of
days
since
the
beginning
of
4713
BCE,
and
Loran-C,
Unix
and
GPS
time
are
based
on
seconds
counted
from
a
specified
origin
in
1958,
1970
and
1980,
respectively.
Archaeological
and
geological
applications
use
chronometric
scales
based
on
years
counted
backwards
from
‘the
present’
(defined
as
1950
for
radiocarbon
dating
[
RC-14
]),
or
using
named
periods
associated
with
specified
correlation
markers
[
CR-05
],
[
,
CR-14
],
[
,
MF-13
].
Dynastic
calendars
(counting
years
within
eras
defined
by
the
reign
of
a
monarch
or
dynasty)
were
used
earlier
in
many
cultures.
In
order
to
support
these
more
general
applications,
the
representation
of
temporal
position
and
duration
must
be
flexible,
and
annotated
with
the
temporal
reference
system
in
use.
A set of ordered intervals (e.g. named dynasties, geological periods, geomagnetic reversals, tree rings) can make a simple form of temporal reference system that supports logical reasoning, known as an ordinal temporal reference system [ ISO-19108 ].
Measurement of duration needs a clock . In its most general form a clock is just a regularly repeating physical event ('tick') and a counting mechanism for the 'ticks'. These counts may be used to logically relate two events and to calculate a duration between the events.
A calendar is a set of algorithms that enables clock counts to be converted into practical everyday dates and times related to the movement of astronomical bodies (day, month, year).
For many purposes it is convenient to make temporal calculations in terms of clock durations that exceed everyday units such as days, weeks, months and years, using a representation of temporal position in a temporal coordinate system [ ISO-19108 ], i.e. on a number line with a specified origin, such as Julian date, or Unix time. This may be converted to calendar units when necessary for human consumption.
Nevertheless, in practice much temporal information is not well-defined, in that there may be no clear statement about the assumed underlying calendar and clock.
OWL
2
has
two
built-in
datatypes
relating
to
time:
xsd:dateTime
and
xsd:dateTimeStamp
[
owl2-quick-reference
OWL-2
].
Other
XSD
types
such
as
xsd:date
,
xsd:gYear
and
,
xsd:gMonth
[
XSD-D
]
are
also
commonly
used
in
OWL
applications.
These
provide
for
a
compact
representation
of
time
positions
using
the
conventional
Gregorian
calendar
and
24-hour
clock,
with
timezone
offset
from
xsd:gMonth
[
xmlschema11-2
xsd:gYearMonth
UTC
if
required.
UTC.
Three
classes
in
the
ontology
support
a
more
explicit
description
of
temporal
position.
All
have
a
property
to
indicate
the
temporal
reference
system
hasTRS
:hasTRS
.
TRS.
:TRS
has
properties
to
alternatively
describe
the
position
using
a
number
(i.e.
a
temporal
coordinate),
or
a
nominal
value
(e.g.
geologic
time
period,
dynastic
name,
archeological
era).
TimePosition
:TimePosition
has
a
set
of
properties
to
specify
a
date-time
using
calendar
and
clock
elements.
Its
subclass
GeneralDateTimeDescription
:GeneralDateTimeDescription
fixes
the
temporal
reference
system
to
the
Gregorian
calendar,
so
the
DateTimeDescription
:DateTimeDescription
property
may
be
omitted
on
individuals
from
this
class.
hasTRS
:hasTRS
Note
DateTimeDescription
covers
the
case
that
was
defined
in
the
original
note,
and
retains
the
original
class
name.
Following
the
theoretical
basis
laid
out
by
Allen
and
Ferguson,
Ferguson
[
AL-84
,
AF-97
],
a
time
position
has
a
finite
extent,
corresponding
to
the
precision
or
temporal
unit
used.
Thus,a
Thus,
a
or
GeneralDateTimeDescription
:GeneralDateTimeDescription
is
strictly
always
a
description
of
an
DateTimeDescription
:DateTimeDescription
interval
(
DateTimeInterval
),
interval,
not
an
instant,
with
a
duration
corresponding
to
the
value
of
its
.
unitType
:unitType
We
use
two
different
sets
of
properties
for
or
GeneralDateTimeDescription
:GeneralDateTimeDescription
and
DateTimeDescription
:DateTimeDescription
or
GeneralDurationDescription
:GeneralDurationDescription
,
because
their
ranges
are
different.
For
example,
DurationDescription
:DurationDescription
(in
year
:year
)
has
a
range
of
DateTimeDescription
:DateTimeDescription
xsd:gYear
,
while
(in
years
:years
)
has
a
range
of
GeneralDurationDescription
:GeneralDurationDescription
xsd:decimal
so
that
you
can
say
duration
of
2.5
years.
The duration of an interval (or temporal sequence) can have many different descriptions. An interval can be 1 day 2 hours, or 26 hours, or 1560 minutes, and so on. It is useful to be able to talk about these descriptions in a convenient way as independent objects, and to talk about their equivalences. An interval can have multiple duration descriptions (e.g., 2 days, 48 hours), but can only have one duration.
Three
classes
support
the
description
of
the
duration
of
an
entity.
entity.
has
properties
to
describe
the
duration
using
a
scaled
number
(i.e.
a
temporal
quantity).
Duration
:Duration
has
a
set
of
properties
to
specify
a
duration
using
calendar
and
clock
elements,
the
definitions
of
which
are
given
in
the
associated
TRS
description.
Its
subclass
GeneralDurationDescription
:GeneralDurationDescription
fixes
the
temporal
reference
system
to
the
Gregorian
calendar,
so
the
DurationDescription
:DurationDescription
property
may
be
omitted
on
individuals
from
this
class.
hasTRS
:hasTRS
In
this
vocabulary
specification,
Manchester
syntax
[
OWL-M
What
]
is
used
where
the
best
value
of
a
field
is
not
a
simple
term
denoted
by
a
URI
or
cURI.
:DateTimeDescription
|
:DateTimeInterval
|
:DayOfWeek
|
:Duration
|
:DurationDescription
|
:GeneralDateTimeDescription
|
:GeneralDurationDescription
|
:Instant
|
:Interval
|
:ProperInterval
|
:TemporalEntity
|
:TemporalUnit
|
:TimePosition
|
:TimeZone
|
:TRS
RDFS Class: |
time:DateTimeDescription
|
---|---|
Definition: |
Description
of
date
and
time
structured
with
separate
values
for
the
various
elements
of
a
calendar-clock
system.
The
temporal
reference
system
is
fixed
to
Gregorian
|
Subclass of: |
time:GeneralDateTimeDescription
|
Subclass of: |
time:hasTRS
value
<http://dbpedia.org/resource/Gregorian_calendar>
|
Subclass of: |
|
Subclass of: |
time:month
only
xsd:gMonth
|
Subclass of: |
time:day
only
xsd:gDay
|
Other
datetime
concepts
can
be
defined
by
specialization
of
:DateTimeDescription
-
see
examples
below
.
RDFS Class: |
time:DateTimeInterval
|
---|---|
Definition: |
time:DateTimeInterval
is
a
subclass
of
time:ProperInterval
,
defined
using
the
multi-element
time:DateTimeDescription
. |
Subclass of: |
time:ProperInterval
|
The
class
:DateTimeInterval
is
a
subclass
of
:ProperInterval
,
being
an
interval
whose
boundaries
fall
on
the
limits
of
a
date-time
description
with
truncated
precision.
Two
properties
:hasDateTimeDescription
and
:xsdDateTime
provide
alternative
representations
of
the
description
of
the
interval.
Any
:TemporalEntity
has
a
duration,
but
only
:DateTimeInterval
can
have
:DateTimeDescription
.
For
example,
May
8
can
be
expressed
as
a
:DateTimeDescription
,
but
the
interval
from
1:30pm,
May
8,
to
1:30pm,
May
9,
cannot.
Both
have
a
duration
of
a
day.
RDFS Class: |
time:DayOfWeek
|
---|---|
Definition: | The day of week |
Instance of: |
owl:Class
|
Seven
individual
members
of
:DayOfWeek
are
included
in
the
ontology,
corresponding
to
the
seven
days
used
in
the
Gregorian
calendar,
and
using
the
English
names
:Sunday
,:Monday
,:Tuesday
,:Wednesday
,:Thursday
,:Friday
,:Saturday
.
Membership
of
the
class
:DayOfWeek
is
open,
to
allow
for
alternative
week
lengths
and
different
day
names.
RDFS Class: |
time:Duration
|
---|---|
Definition: | Duration of a temporal extent expressed as a number scaled by a temporal unit |
Instance of: |
owl:Class
|
Subclass of: |
time:numericDuration
exactly
1
|
Subclass of: |
time:unitType
exactly
1
|
RDFS Class: |
time:DurationDescription
|
---|---|
Definition: |
Description
of
temporal
extent
structured
with
separate
values
for
the
|
Subclass of: |
time:GeneralDurationDescription
|
Subclass of: |
time:hasTRS
value
<http://dbpedia.org/resource/Gregorian_calendar>
|
Subclass of: |
time:years
only
xsd:decimal
|
Subclass of: |
time:months
only
xsd:decimal
|
Subclass of: |
time:weeks
only
xsd:decimal
|
Subclass of: |
time:days
only
xsd:decimal
|
Subclass of: |
time:hours
only
xsd:decimal
|
Subclass of: |
time:minutes
only
xsd:decimal
|
Subclass of: |
time:seconds
only
xsd:decimal
|
Other duration concepts can be straightforwardly defined - see examples below .
RDFS Class: |
time:GeneralDateTimeDescription
|
---|---|
Definition: | Description of date and time structured with separate values for the various elements of a calendar-clock system |
Instance of: |
owl:Class
|
Subclass of: |
time:hasTRS
exactly
1
|
Subclass of: |
time:timeZone
max
1
|
Subclass of: |
time:unitType
exactly
1
|
Subclass of: |
time:year
max
1
|
Subclass of: |
time:month
max
1
|
Subclass of: |
time:day
max
1
|
Subclass of: |
time:hour
max
1
|
Subclass of: |
time:minute
max
1
|
Subclass of: |
time:second
exactly
1
|
Subclass of: |
time:week
max
1
|
Subclass of: |
time:dayOfYear
max
1
|
Subclass of: |
time:dayOfWeek
max
1
|
Three
properties
:hasTRS
,:timeZone
,
and
:unitType
provide
for
reference
information
concerning
the
reference
system
and
precision
of
temporal
duration.
position
values.
Six
datatype
properties
:year
,
Note
:month
,
:day
,
:hour
,
:minute
,
:second
,
together
with
:timeZone
support
the
description
of
components
of
a
temporal
position
in
a
calendar-clock
system.
These
classes
address
correspond
with
the
'duration'
requirement
from
5.7
Date,
time
'seven
property
model'
described
in
ISO
8601
[
ISO-8601
]
and
duration
XML
Schema
Definition
Language
Part
2:
Datatypes
[
XSD-D
],
except
that
the
calendar
is
not
specified
in
advance,
but
is
provided
through
the
value
of
the
:hasTRS
property
(defined
above).
Two
additional
properties
and
6.
Vocabulary
specification
:week
allow
for
the
the
numeric
value
of
the
week
or
day
relative
to
the
year.
Note
:dayOfYear
The
SDWWG
requirement
5.25
Multilingual
property
:dayOfWeek
provides
the
name
of
the
day.
RDFS Class: |
time:GeneralDurationDescription
|
---|---|
Definition: | Description of temporal extent structured with separate values for the various elements of a calendar-clock system. |
Instance of: |
owl:Class
|
Subclass of: |
time:hasTRS
exactly
1
|
Subclass of: |
time:years
max
1
|
Subclass of: |
time:months
max
1
|
Subclass of: |
time:weeks
max
1
|
Subclass of: |
time:days
max
1
|
Subclass of: |
time:hours
max
1
|
Subclass of: |
time:minutes
max
1
|
Subclass of: |
time:seconds
max
1
|
Seven
datatype
properties
:years
,:months
,:weeks
,:days
,:hours
,:minutes
,
and
:seconds
support
the
description
of
components
of
a
temporal
extent
in
a
calendar-clock
system.
RDF Class: |
time:Instant
|
---|---|
Definition: | A temporal entity with zero extent or duration |
Subclass of: |
time:TemporalEntity
|
Seven
properties,
:inXSDDate
,:inXSDDateTime
(deprecated),
:inXSDDateTimeStamp
,:inXSDgYear
,:inXSDgYearMonth
,:inTimePosition
,
and
:inDateTime
provide
alternative
ways
to
describe
the
documentation
temporal
position
of
the
ontology.
an
:Instant
.
RDF Class: |
|
---|---|
Definition: | A temporal entity with an extent or duration |
Subclass of: |
time:TemporalEntity
|
One
property
:inside
links
to
an
:Instant
that
falls
inside
the
:Interval
.
RDF
Class:
|
time:ProperInterval
|
---|---|
Definition: | A temporal entity with non-zero extent or duration, i.e. for which the value of the beginning and end are different |
Subclass of: |
time:Interval
|
Disjoint with: |
time:Instant
|
Thirteen
properties
:intervalBefore
,:intervalAfter
,:intervalMeets
,:intervalMetBy
,:intervalOverlaps
,:intervalOverlappedBy
,:intervalStarts
,:intervalStartedBy
,:intervalDuring
,:intervalContains
,:intervalFinishes
,:intervalFinishedBy
,:intervalEquals
support
the
set
of
interval
relations
defined
by
Allen
and
Ferguson
[
AF-97
].
RDF Class: |
time:TemporalEntity
|
---|---|
Definition: | A temporal interval or instant. |
Instance of: |
owl:Class
|
Union of: |
[
time:Instant
,
time:Interval
]
|
Two
properties,
,
before
:before
,
support
ordering
relationships
between
two
after
:after
s.
TemporalEntity
:TemporalEntity
Two
properties,
:hasBeginning
,:hasEnd
,
support
the
describing
the
bounds
of
a
:TemporalEntity
.
Two
properties,
:hasDuration
,:hasDurationDescription
,
provide
alternative
ways
to
describe
the
extent
of
a
:TemporalEntity
.
One
property
:hasMember
supports
the
inclusion
of
temporal
entities
in
other
resources.
RDFS Class: |
time:TemporalEntity
|
---|---|
Definition: | A temporal unit of measure, which provides a scale factor for a time quantity. |
Instance of: |
owl:Class
|
Seven
individual
members
of
:TemporalUnit
are
included
in
the
ontology,
corresponding
to
the
elements
of
the
standard
calendar-clock:
:unitYear
,:unitMonth
,:unitWeek
,:unitDay
,:unitHour
,:unitMinute
and
:unitSecond
.
Membership of the class TemporalUnit is open, to allow for other temporal units used in some technical applications (e.g. millions of years, Baha'i month).
RDF Class: |
time:TimePosition
|
---|---|
Definition: | A temporal position described using either a (nominal) value from an ordinal reference system, or a (numeric) value in a temporal coordinate system. |
Instance of: |
owl:Class
|
Subclass of: |
time:hasTRS
exactly
1
|
Subclass of: |
(
time:numericPosition
exactly
1
)
or
(
time:nominalPosition
exactly
1
)
|
Two
properties
:nominalPosition
and
:numericPosition
support
the
alternative
descriptions
of
position
or
extent.
One
of
these
is
expected
to
be
present.
The
temporal
ordinal
reference
system
should
be
provided
as
the
value
of
the
:hasTRS
property
The
temporal
coordinate
system
should
be
provided
as
the
value
of
the
:hasTRS
property
RDFS Class: |
time:TimeZone
|
---|---|
Definition: | A Time Zone is a geographic region that uses a clock with a specified offset from UTC. The region and offset are specified by the locally recognised governing authority. |
Instance of: |
owl:Class
|
No
specific
properties
are
provided
for
the
class
:TimeZone
,
the
definition
of
which
is
beyond
the
scope
of
this
ontology.
The
class
specified
here
is
a
stub,
effectively
the
superclass
of
all
time
zone
classes.
An
ontology
for
time
zone
descriptions
was
described
in
[
OWL-T
]
and
provided
as
RDF
in
a
separate
namespace
tzont:
.
However,
that
ontology
was
incomplete
in
scope,
and
the
example
datasets
were
selective.
Furthermore,
the
use
of
a
class
from
an
external
ontology
as
the
range
of
an
ObjectProperty
in
OWL-Time
creates
an
undesirable
dependency.
Therefore,
reference
to
the
time
zone
class
has
been
replaced
with
the
'stub'
class
in
the
normative
part
of
this
version
of
OWL-Time.
IETF and IANA also provide databases. These are well maintained, but individual iems are not available at individual URIs, i.e. not as "Linked Data".
The World Clock service provides a list of time zones , with the description of each available as an individual webpage with a convenient individual URI (e.g. https://www.timeanddate.com/time/zones/acwst . Currently this appears to offer best practice.
RDFS Class: |
time:TRS
|
---|---|
Definition: | A temporal reference system, such as a temporal coordinate system (with an origin, direction, and scale), a calendar-clock combination, or a (possibly hierarchical) ordinal system. |
Instance of: |
owl:Class
|
No
specific
properties
are
provided
for
the
class
:TRS
,
the
definition
of
which
is
beyond
the
scope
of
this
ontology.
The
class
specified
here
is
a
stub,
effectively
the
superclass
of
all
temporal
reference
system
types.
Note
that
an
ordinal
temporal
reference
system,
such
as
the
geologic
timescale,
may
be
represented
directly,
using
this
ontology,
as
a
set
of
:ProperInterval
s,
along
with
enough
inter-relationships
to
support
the
necessary
ordering
relationships.
See
example
below
of
Geologic
Timescale
.
A model and ontology for temporal reference system definitions is required. A taxonomy of temporal reference systems is provided in ISO 19108:2002 [ ISO-19108 ], including (a) calendar + clock systems; (b) temporal coordinate systems (i.e. numeric offset from an epoch); (c) temporal ordinal reference systems (i.e. ordered sequence of named intervals, not necessarily of equal duration).
:after
|
:before
|
:day
|
:days
|
:dayOfWeek
|
:dayOfYear
|
:hasBeginning
|
:hasDuration
|
:hasDateTimeDescription
|
:hasDurationDescription
|
:hasEnd
|
:hasMember
|
:hasTRS
|
:hour
|
:hours
|
:inside
|
:intervalAfter
|
:intervalBefore
|
:intervalContains
|
:intervalDuring
|
:intervalEquals
|
:intervalFinishedBy
|
:intervalFinishes
|
:intervalMeets
|
:intervalMetBy
|
:intervalOverlappedBy
|
:intervalOverlaps
|
:intervalStartedBy
|
:intervalStarts
|
:inTimePosition
|
:inDateTime
|
:inXSDDate
|
:inXSDDateTime
|
:inXSDDateTimeStamp
|
:inXSDgYear
|
:inXSDgYearMonth
|
:minute
|
:minutes
|
:month
|
:months
|
:nominalPosition
|
:numericDuration
|
:numericPosition
|
:second
|
:seconds
|
:timeZone
|
:unitType
|
:week
|
:weeks
|
:xsdDateTime
|
:year
|
:years
RDF Property: |
time:after
|
---|---|
Definition: |
Gives
directionality
to
time.
If
a
temporal
entity
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:before
|
RDF Property: |
time:before
|
---|---|
Definition: |
Gives
directionality
to
time.
If
a
temporal
entity
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:TemporalEntity
|
Range: |
time:TemporalEntity
|
RDF Property: |
time:day
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:GeneralDateTimeDescription
|
RDF Property: |
|
---|---|
Definition: |
The
day
of
week,
whose
value
is
a
member
of
the
class
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:GeneralDateTimeDescription
|
Range: |
time:DayOfWeek
|
RDF Property: |
time:dayOfYear
|
---|---|
Definition: |
The
number
of
the
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:GeneralDateTimeDescription
|
Range: |
xsd:nonNegativeInteger
|
RDF Property: |
time:days
|
---|---|
Definition: | length of a temporal extent expressed in days |
Instance of: |
|
Domain: |
time:GeneralDurationDescription
|
Range: |
time:Number
|
RDF Property: |
time:hasBeginning
|
---|---|
Definition: | Beginning of a temporal entity. |
Instance of: |
owl:ObjectProperty
|
Domain: |
time:TemporalEntity
|
Range: |
time:Instant
|
RDF Property: |
time:hasDateTimeDescription
|
---|---|
Definition: |
time:DateTimeInterval
expressed
as
a
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:DateTimeInterval
|
Range: |
time:GeneralDateTimeDescription
|
RDF Property: |
time:hasDuration
|
---|---|
Definition: | Duration of a temporal entity, expressed as a scaled value or nominal value |
Instance of: |
owl:ObjectProperty
|
Domain: |
time:TemporalEntity
|
Range: |
time:Duration
|
RDF Property: |
time:hasDurationDescription
|
---|---|
Definition: | Duration of a temporal entity, expressed using a structured description |
Instance of: |
owl:ObjectProperty
|
Domain: |
time:TemporalEntity
|
Range: |
time:DurationDescription
|
RDF Property: | time:hasEnd |
---|---|
Definition: |
End
of
a
temporal
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:TemporalEntity
|
Range: |
time:Instant
|
RDF Property: | time:hasMember |
---|---|
Definition: | Supports the inclusion of temporal entities in other resources, such as temporal reference systems. |
Instance of: |
owl:ObjectProperty
|
Range: |
time:TemporalEntity
|
RDF
|
time:hasTRS
|
---|---|
Definition: |
|
|
owl:ObjectProperty
|
Instance of: |
owl:FunctionalProperty
|
Range: |
time:TRS
|
RDF Property: |
|
---|---|
Definition: | Hour position in a calendar-clock system |
Instance of: |
|
Domain: |
|
Range: |
xsd:nonNegativeInteger
|
RDF Property: |
time:hours
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:GeneralDurationDescription
|
Range: |
time:Number
|
RDF
|
time:inDateTime
|
---|---|
Definition: |
|
|
owl:ObjectProperty
|
|
time:Instant
|
Range: |
time:GeneralDateTimeDescription
|
RDF Property: |
time:inside
|
---|---|
Definition: |
An
instant
that
falls
inside
the
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:Interval
|
Range: |
time:Instant
|
RDF Property: |
time:intervalAfter
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:intervalBefore
|
RDF Property: |
time:intervalBefore
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
intervalBefore
another
proper
interval
T
2
,
then
the
end
of
T
1
is
before
the
beginning
of
T
2
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:ProperInterval
|
Range: |
time:ProperInterval
|
SubProperty of: |
time:before
|
RDF Property: |
time:intervalContains
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
Inverse of: |
time:intervalDuring
|
RDF Property: |
time:intervalDuring
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:ProperInterval
|
Range: |
time:ProperInterval
|
RDF Property: |
time:intervalEquals
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:ProperInterval
|
Range: |
time:ProperInterval
|
RDF Property: |
time:intervalFinishedBy
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:intervalFinishes
|
RDF Property: |
time:intervalFinishes
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:ProperInterval
|
Range: |
time:ProperInterval
|
RDF Property: |
time:intervalMeets
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:ProperInterval
|
Range: |
time:ProperInterval
|
RDF Property: |
time:intervalMetBy
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
Inverse of: |
time:intervalMeets
|
RDF Property: |
time:intervalOverlappedBy
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:intervalOverlaps
|
RDF Property: |
time:intervalOverlaps
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:ProperInterval
|
Range: |
time:ProperInterval
|
RDF Property: |
time:intervalStartedBy
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
time:intervalStarts
|
RDF Property: |
time:intervalStarts
|
---|---|
Definition: |
If
a
proper
interval
T
1
is
|
Instance of: |
owl:ObjectProperty
|
|
|
|
time:ProperInterval
|
RDF Property: |
time:inTimePosition
|
---|---|
Definition: |
|
Instance of: |
owl:ObjectProperty
|
Domain: |
time:Instant
|
Range: |
time:TimePosition
|
RDF Property: |
time:inXSDDate
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:Instant
|
Range: |
|
RDF
|
time:inXSDDateTime
|
---|---|
Definition: |
xsd:dateTime
|
|
owl:DatatypeProperty
|
Domain: |
|
Range: |
|
Deprecated: |
|
RDF Property: |
time:inXSDDateTimeStamp
|
---|---|
Definition: |
Position
of
an
instant,
expressed
using
xsd:dateTimeStamp
,
in
which
the
time-zone
field
is
mandatory
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:Instant
|
Range: |
xsd:dateTimeStamp
|
This
property
(Was
local
Issue
8)
time:inXSDDateTime
uses
xsd:dateTime
which
was
available
in
OWL
v1.
The
datatype
xsd:dateTimeStamp
,
which
makes
the
timezone
element
mandatory
instead
of
optional,
was
added
in
OWL2.
Should
anything
be
added
to
OWL-Time
to
allow
Use
of
xsd:dateTimeStamp
is
recommended.
time:inXSDDateTime
is
retained
for
this?
Need
to
balance
backward
compatibility
concerns.
backward-compatibility,
but
marked
'deprecated'.
See
SDWWG
requirement
5.53
5.58
Update
datatypes
in
OWL
Time
RDF Property: |
time:inXSDgYear
|
---|---|
Definition: |
Position
of
an
instant,
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:Instant
|
Range: |
xsd:gYear
|
RDF Property: |
time:inXSDgYearMonth
|
---|---|
Definition: |
Position
of
an
instant,
expressed
using
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:Instant
|
Range: |
|
RDF Property: |
time:minute
|
---|---|
Definition: |
|
Instance of: |
|
Domain: |
|
Range: |
|
RDF Property: |
time:minutes
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
|
time:GeneralDurationDescription
|
Range: |
time:Number
|
RDF Property: |
|
---|---|
Definition: |
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
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
|
RDF
|
time:months
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
|
time:GeneralDurationDescription
|
|
time:Number
|
RDF Property: |
time:nominalPosition
|
---|---|
Definition: | The (nominal) value indicating temporal position in an ordinal reference system |
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:TimePosition
|
Range: |
xsd:string
|
RDF Property: |
time:numericDuration
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:Duration
|
Range: |
time:Number
|
RDF Property: |
time:numericPosition
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
|
time:TimePosition
|
|
time:Number
|
RDF Property: |
time:second
|
---|---|
|
|
|
owl:DatatypeProperty
|
|
time:GeneralDateTimeDescription
|
|
xsd:decimal
|
RDF Property: |
time:seconds
|
---|---|
|
|
|
owl:DatatypeProperty
|
|
time:GeneralDurationDescription
|
|
time:Number
|
RDF Property: |
time:timeZone
|
---|---|
Definition: | The time zone for clock elements in the temporal position |
Instance of: |
owl:ObjectProperty
|
Domain: |
time:GeneralDateTimeDescription
|
Range: |
time:TimeZone
|
RDF Property: |
time:unitType
|
---|---|
Definition: | The temporal unit which provides the precision of a date-time value or scale of a temporal extent |
Instance of: |
owl:ObjectProperty
|
Domain: |
time:GeneralDateTimeDescription
or
time:Duration
|
Range: |
time:TemporalUnit
|
The
property
:unitType
(defined
above)
support
indicates
the
description
of
components
precision
of
a
temporal
time
position
in
a
calendar-clock
system.
These
correspond
with
the
'seven
property
model'
described
in
ISO
8601
[
or
duration,
when
that
is
expressed
using
or
ISO-8601
:GeneralDateTimeDescription
]
and
XML
Schema
Definition
Language
Part
2:
Datatypes
[
.
Seven
individual
unitTypes
are
included
in
xmlschema11-2
:DateTimeDescription
],
except
that
the
calendar
is
not
specified
advance,
but
is
provided
through
the
value
of
ontology,
corresponding
to
the
hasTRS
property
(defined
above).
conventional
clock-calendar
units.
RDF Property: |
time:week
|
---|---|
|
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
|
Range: |
xsd:nonNegativeInteger
|
RDF Property: |
:weeks
|
---|---|
|
|
|
owl:DatatypeProperty
|
Domain: |
time:GeneralDurationDescription
|
Range: |
time:Number
|
How
to
use
week
:xsdDateTime
and
to
describe
a
dayOfYear
:DateTimeInterval
allow
for
the
the
numeric
value
of
the
week
or
day
relative
is
unclear
at
best,
and
appears
to
be
untested.
Propose
deprecating
it
in
the
year.
ontology,
and
removing
it
from
the
rec
document.
RDF Property: |
time:xsdDateTime
|
---|---|
Definition: |
Value
of
time:DateTimeInterval
expressed
as
a
compact
value.
The
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:DateTimeInterval
|
Range: |
xsd:dateTime
|
(Was local Issue 7) Verify that this satisfies the SDWWG requirement 5.58 Update datatypes in OWL Time
RDF Property: |
time:year
|
---|---|
Definition: |
Year
position
in
a
calendar-clock
system.
The
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:GeneralDateTimeDescription
|
RDF Property: |
time:years
|
---|---|
Definition: |
|
Instance of: |
owl:DatatypeProperty
|
Domain: |
time:GeneralDurationDescription
|
Range: |
time:Number
|
time:DayOfWeek
Definition:
The
day
of
week
:generalDay
Instance
of:
owl:Class
Seven
individual
members
of
DayOfWeek
are
included
in
the
ontology,
corresponding
to
the
seven
days
used
in
the
Gregorian
calendar,
and
using
the
English
names
Sunday
,
Monday
,
Tuesday
,
Wednesday
,
Thursday
,
|
|
Friday
,
:generalMonth
|
Saturday
.
Note
:generalYear
In
this
version
of
the
ontology,
membership
of
the
class
DayofWeek
is
open,
to
allow
for
alternative
week
lengths
and
different
day
names.
:Number
6.10
Class:
DateTimeDescription
RDFS Class: |
time:generalDay
|
---|---|
Definition: |
xsd:gDay
,
formulated
as
a
xsd:gDay
,
except
that
values
up
to
|
|
rdfs:Datatype
|
Subclass of: |
owl:onDatatype xsd:string ;
owl:withRestrictions (
[
xsd:pattern "---(0[1-9]|[1-9][0-9])(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
]
)
|
RDFS Class: |
time:generalMonth
|
---|---|
Definition: |
xsd:gMonth
,
formulated
as
a
,
except
that
values
up
to
20
are
|
Instance of: |
rdfs:Datatype
|
Subclass of: |
owl:onDatatype xsd:string ;
owl:withRestrictions (
[
xsd:pattern "--(0[1-9]|1[0-9]|20)(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
]
)
|
RDFS Class: |
time:generalYear
|
---|---|
Definition: |
xsd:gYear
,
formulated
as
a
xsd:gYear
.
Note
that
the
value-space
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
of
values
of
this
type.
|
Instance of: |
rdfs:Datatype
|
|
owl:onDatatype xsd:string ;
owl:withRestrictions (
[
xsd:pattern "-?([1-9][0-9]{3,}|0[0-9]{3})(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string ;
]
)
|
RDFS Class: |
time:Number
|
---|---|
Definition: |
|
Instance of: |
rdfs:Datatype
|
|
xsd:double
or
xsd:float
or
xsd:decimal
|
Seven
The
datatype
properties
provides
for
numbers
expressed
using
any
of
the
XSD
types
years
,
:Number
(of
which
months
,
xsd:decimal
is
a
sub-type),
weeks
,
xsd:integer
,
or
days
xsd:float
(which
allows
exponential
or
scientific
notation).
hours
,
xsd:double
|
minute
,
and
:Friday
seconds
:Monday
support
the
description
of
components
of
a
temporal
extent
in
a
calendar-clock
system.
These
correspond
with
the
'seven
property
model'
described
in
ISO
8601
[
|
|
ISO-8601
:Saturday
]
and
XML
Schema
Definition
Language
Part
2:
Datatypes
[
|
xmlschema11-2
:Sunday
],
except
that
the
calendar
is
not
specified
in
advance.
:Thursday
|
:Tuesday
|
:Wednesday
|
:unitDay
|
:unitHour
|
:unitMinute
|
:unitMonth
|
:unitSecond
|
:unitWeek
|
:unitYear
Class |
|
---|---|
time:DayOfWeek
|
time:Friday
|
time:DayOfWeek
|
time:Monday
|
time:DayOfWeek
|
time:Saturday
|
time:DayOfWeek
|
time:Sunday
|
time:DayOfWeek
|
time:Thursday
|
time:DayOfWeek
|
time:Tuesday
|
time:DayOfWeek
|
time:Wednesday
|
time:TemporalUnit
|
time:unitDay
|
time:TemporalUnit
|
time:unitHour
|
time:TemporalUnit
|
time:unitMinute
|
time:TemporalUnit
|
time:unitMonth
|
time:TemporalUnit
|
time:unitSecond
|
time:TemporalUnit
|
time:unitWeek
|
time:TemporalUnit
|
time:unitYear
|
This
section
is
non-normative.
The
following
example
illustrates
the
difference
between
using
and
using
the
time:DurationDescription
:DateTimeDescription
Definition:
Description
of
temporal
extent
structured
with
separate
values
for
the
various
elements
of
a
calendar-clock
system.
The
temporal
reference
system
is
fixed
to
Gregorian
Calendar,
range
of
each
of
the
numeric
properties
is
restricted
to
xsd:decimal
Subclass
of:
time:GeneralDurationDescription
Subclass
of:
time:hasTRS
value
<http://dbpedia.org/resource/Gregorian_calendar>
Subclass
of:
time:years
only
xsd:decimal
Subclass
of:
time:months
only
xsd:decimal
Subclass
of:
time:weeks
only
xsd:decimal
Subclass
of:
time:days
only
xsd:decimal
Subclass
of:
time:hours
only
xsd:decimal
Subclass
of:
time:minutes
only
xsd:decimal
Subclass
of:
time:seconds
only
xsd:decimal
Other
duration
concepts
can
be
straightforwardly
defined.
For
example,
duration
"Year"
could
be
defined
as
a
subclass
of
"DurationDescription"
with
the
restrictions
XML
datatype
xsd:dateTimeStamp
.
An
instant
that
represents
the
"years"
property
is
required
(with
"cardinality"
start
of
1)
and
all
other
properties
(e.g.,
"hours",
"months")
should
not
a
meeting,
called
ex:meetingStart
,
happens
at
10:30am
EST
on
01/01/2006
can
be
present
(with
"cardinality"
of
0):
Note
expressed
using
both
:inXSDDateTime
:Year
was
the
only
specialization
of
:DurationDescription
and
:inDateTime
defined
in
the
original
OWL-Time.
It
has
been
retained
but
marked
"deprecated".
OWL
as:
ex:meetingStart
a :Instant ;
:inDateTime ex:meetingStartDescription ;
:inXSDDateTimeStamp 2006-01-01T10:30:00-5:00 .
rdfs:subClassOf
[ a owl:Restriction ;
owl:cardinality 0 ;
owl:onProperty :seconds
] .
ex:meetingStartDescription
a :DateTimeDescription ;
:unitType :unitMinute ;
:minute 30 ;
:hour 10 ;
:day 1 ;
:dayOfWeek :Sunday ;
:dayOfYear 1 ;
:week 1 ;
:month 1 ;
:timeZone <https://www.timeanddate.com/time/zones/est> ;
:year 2006 .
We
It
is
much
more
concise
to
use
"cardinality
=
0"
instead
of
restricting
the
values
of
days,
etc.
to
0.
The
reason
is
that
XML
Schema
datatype
xsd:dateTimeStamp
.
However,
using
"cardinality
=
0"
means
all
those
properties/fields
(days,
etc.)
should
not
:DateTimeDescription
more
information
can
be
specified
(i.e.,
expressed,
such
as
"week",
"day
of
week"
and
"day
of
year",
so
in
the
granularity
example,
we
can
also
know
that
01/01/2006
is
"year"),
while
restricting
all
those
values
to
0
means
they
all
have
a
fixed
value
Sunday,
on
the
first
day
of
0
(i.e.,
x
years
0
months
0
days
...)
the
year,
and
in
the
granularity
first
week
of
the
year.
Since,
each
field
of
:DateTimeDescription
is
actually
"second",
which
separate
it
is
not
easier
to
extract
the
correct
semantics
value
of
"year".
some
fields
for
the
later
use
and
easier
to
reason
about.
Note
that
there
is
a
distinction
between
a
year
as
a
duration
and
a
calendar
year.
The
year
from
December
22,
2006
:timeZone
property
points
to
December
21,
2007
is
the
former
but
not
the
latter.
a
definition
of
US
Eastern
Standard
Time.
The
datatype
use
of
different
temporal
reference
systems
for
the
same
absolute
time
is
illustrated
in
the
following
examples.
Abby's
birthday
is
an
Number
:Instant
provides
for
numbers
whose
position
may
be
expressed
using
any
of
the
conventional
XSD
types
decimal
(of
which
xsd:integer
xsd:dateTimeStamp
is
a
sub-type),
float
,
or
type
as
:
double
(which
allows
exponential
or
scientific
notation).
2001-05-23T08:20:00+08:00
ex:AbbyBirthday
a :Instant ;
:inDateTime ex:AbbyBirthdayHebrew ;
:inTimePosition ex:AbbyBirthdayUnix ;
rdfs:label "Abby's birthdate"^^xsd:string ;
:inDateTime ex:AbbyBirthdayGregorian ;
:inXSDDateTime "2001-05-23T08:20:00+08:00"^^xsd:dateTimeStamp ;
.
Using
the
class,
the
elements
of
the
date
and
time
using
the
Gregorian
Calendar
are
split
out
into
separate
properties:
6.16
Datatype:
generalYear
:DateTimeDescription
RDFS
Class:
ex:AbbyBirthdayGregorian
a :DateTimeDescription ;
:day "---23"^^xsd:gDay ;
:dayOfWeek :Wednesday ;
:hour "8"^^xsd:nonNegativeInteger ;
:minute "20"^^xsd:nonNegativeInteger ;
:month "--05"^^xsd:gMonth ;
:timeZone <https://www.timeanddate.com/time/zones/awst> ;
:unitType :unitMinute ;
:year "2001"^^xsd:gYear ;
.
The
class
may
be
used
to
time:generalYear
:GeneralDateTimeDescription
Definition:
Year
number
-
generalization
of
xsd:gYear,
formulated
as
a
text
string
with
a
pattern
constraint
reproduce
express
the
same
lexical
form
as
gYear.
Note
that
date
using
the
value-space
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
of
values
of
this
type.
Instance
of:
rdfs:Datatype
Subclass
of:
owl:onDatatype
xsd:string
;
owl:withRestrictions
(
[
xsd:pattern
"-?([1-9][0-9]{3,}|0[0-9]{3})(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string
;
]
)
Hebrew
calendar:
ex:AbbyBirthdayHebrew
a :GeneralDateTimeDescription ;
:day "---01"^^:generalDay ;
:hasTRS <http://dbpedia.org/resource/Hebrew_calendar> ;
:month "--03"^^:generalMonth ;
:year "5761"^^:generalYear ;
:unitType :unitDay ;
.
The
class
may
be
used
to
express
the
Note
:TimePosition
While
this
pattern
achieves
correct
lexical
form,
same
position
on
the
value-space
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
Unix
time
scale
(i.e.
the
number
of
values
seconds
since
1st
January
1970):
ex:AbbyBirthdayUnix
a :TimePosition ;
:hasTRS <http://dbpedia.org/resource/Unix_time> ;
:numericPosition 990577200 ;
rdfs:label "Abby's birthdate in Unix time"^^xsd:string ;
.
Each of these examples refers to either a temporal reference system or time zone described externally, using its URI. RDF representations are available from DBPedia (e.g. http://dbpedia.org/resource/Unix_time ) though these do not have specific time semantics.
The
RDF
representation
of
this
type.
example
is
available
here
.
For
the
purposes
of
xsd:gMonth,
formulated
as
a
text
string
with
a
pattern
constraint
to
reproduce
radiocarbon
dating
(which
is
the
same
lexical
form
as
gMonth,
except
that
values
up
to
20
are
permitted,
technique
used
in
order
geological
age
determination
for
materials
up
to
support
calendars
with
more
than
12
months
in
the
year.
Note
that
the
value-space
around
60,000
years
old)
'the
Present'
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
of
values
of
this
type.
Instance
of:
rdfs:Datatype
Subclass
of:
owl:onDatatype
xsd:string
;
owl:withRestrictions
(
conventionally
fixed
at
1950
[
xsd:pattern
"--(0[1-9]|1[0-9]|20)(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string
;
]
)
RC-14
].
This
can
be
described
as
an
individual
,
with
its
position
expressed
using
any
of
Note
:Instant
While
this
pattern
achieves
the
correct
lexical
form,
the
value-space
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
of
values
this
type.
the
three
alternatives:
geol:Present
a :Instant ;
:inDateTime [
a :DateTimeDescription ;
:unitType :unitYear ;
:year "1950"^^xsd:gYear ;
] ;
:inTimePosition [
a :TimePosition ;
:hasTRS <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
:numericPosition "0.0"^^:Number ;
] ;
:inXSDDateTime "1950-01-01T00:00:00Z"^^xsd:dateTimeStamp ;
rdfs:label "The present"^^xsd:string ;
.
Expressed
using
:
the
:
6.18
Datatype:
generalDay
:DateTimeDescription
RDFS
Class:
-
time:generalDay
:unitType
Definition:
Day
of
month
generalization
of
xsd:gDay,
formulated
as
a
text
string
with
a
pattern
constraint
to
reproduce
which
determines
the
same
lexical
form
as
gDay,
except
that
values
up
to
99
are
permitted,
in
order
precision
-
is
set
to
support
calendars
with
more
than
31
days
:unitYear
,
and
only
the
:year
element
is
provided
in
a
month.
Note
that
the
value-space
value.
The
TRS
value
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
of
values
of
this
type.
Instance
of:
rdfs:Datatype
Subclass
of:
owl:onDatatype
xsd:string
;
owl:withRestrictions
(
[
xsd:pattern
"---(0[1-9]|[1-9][0-9])(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?"^^xsd:string
;
]
)
provided
explicitly,
as
it
is
fixed
in
the
ontology
description
to
http://www.opengis.net/def/uom/ISO-8601/0/Gregorian
.
In
the
variant,
the
Note
:TimePosition
While
this
pattern
achieves
the
correct
lexical
form,
value-space
TRS
is
not
defined,
so
a
generic
OWL2
processor
cannot
compute
ordering
relationships
given
as
http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime
which
has
units
of
values
millions
of
this
type.
years,
starting
from
the
present,
positive
backwards.
For
the
value
expressed
using
xsd:dateTimeStamp
the
position
within
the
year
is
set
arbitrarily
to
midnight
at
the
beginning
of
1st
January.
This
section
level
of
precision
is
non-normative.
strictly
spurious,
but
is
required
to
satisfy
the
lexical
pattern
of
the
datatype.
iCalendar
[
RFC2445
DE-09
]
is
a
widely
supported
standard
for
personal
data
interchange.
It
provides
the
definition
of
a
common
format
for
openly
exchanging
calendaring
and
scheduling
information
across
the
Internet.
The
representation
of
temporal
concepts
in
this
time
ontology
can
be
straightforwardly
mapped
to
iCalendar.
For
example,
duration
of
15
days,
5
hours
and
20
seconds
is
represented
in
iCalendar
as
P15DT5H0M20S,
which
can
be
represented
in
the
time
ontology
as:
:hasDurationDescription
;
20 ;
5 ;
15 .
a :DurationDescription ;
:seconds 20 ;
:hours 5 ;
:days 15 .
The iCalendar homepage features the example of Abraham Lincoln's birthday as celebrated in 2008. This may be represented in multiple ways using OWL-Time, including the following.
As
a
:DateTimeInterval
using
the
:DateTimeDescription
form:
_:DTI-1
rdf:type :DateTimeInterval ;
dc:coverage """LOCATION:Hodgenville, Kentucky
GEO:37.5739497;-85.7399606""" ;
dc:date "2015-04-21T14:14:03.00"^^xsd:dateTimeStamp ;
dc:description """Born February 12\\, 1809\\nSixteenth President (1861-1865)
http://AmericanHistoryCalendar.com""" ;
dc:subject "Civil War People" ;
dc:subject "U.S. Presidents" ;
rdfs:label "Abraham Lincoln" ;
skos:closeMatch <2008-04-28-04-15-56-62-@americanhistorycalendar.com> ;
:hasDateTimeDescription [
rdf:type :DateTimeDescription ;
:day "---12"^^xsd:gDay ;
:hasTRS <http://www.opengis.net/def/uom/ISO-8601/0/Gregorian> ;
:month "--02"^^xsd:gMonth ;
:unitType :unitDay ;
:year "2008"^^xsd:gYear ;
] ;
.
The
boundaries
of
the
interval
are
implicitly
the
beginning
and
end
of
the
day
specified
in
the
:DateTimeDescription
.
As
a
:DateTimeInterval
using
the
:xsdDateTime
form:
al:DTI-3 rdf:type :DateTimeInterval ; rdfs:label "Abraham Lincoln" ; :xsdDateTime "2008-02-12T00:00:00.00-05:00"^^xsd:dateTimeStamp ;
.
In
this
formulation,
the
length
of
the
entity
is
implicitly
one
day,
as
there
is
no
sub-day
value
provided
in
the
:xsdDateTime
property.
As
a
:TemporalEntity
using
the
:TimePosition
to
define
the
beginning
and
end:
_:TE-2
rdf:type :TemporalEntity ;
rdfs:label "Abraham Lincoln" ;
:hasBeginning [
rdf:type :Instant ;
:inTimePosition [
rdf:type :TimePosition ;
:hasTRS <http://dbpedia.org/resource/Unix_time> ;
:numericPosition "1202752800"^^:Number ;
] ;
] ;
:hasDuration [
rdf:type :Duration ;
:numericDuration "1"^^:Number ;
:unitType :unitDay ;
] ;
:hasEnd [
rdf:type :Instant ;
:inTimePosition [
rdf:type :TimePosition ;
:hasTRS <http://dbpedia.org/resource/Unix_time> ;
:numericPosition "1202839200"^^:Number ;
] ;
] ;
.
In
this
formulation,
the
length
of
the
entity
is
explict,
as
the
value
of
the
:hasDuration
property.
Several other formulations are possible, some of which are shown in the RDF representation is available here .
The
geologic
timescale
is
defined
as
a
set
of
named
intervals
arranged
in
a
hierarchy,
such
that
there
is
only
one
subdivision
of
the
intervals
of
each
rank
(e.g.
'Era')
by
a
set
of
intervals
of
the
next
rank
(in
this
case
'Period')
[
CR-05
].
Since
the
relative
ordering
is
well-defined
this
graph
can
therefore
serve
as
an
ordinal
temporal
reference
system.
Fig.
5
shows
how
the
geologic
timescale
can
be
expressed
as
a
set
of
:ProperIntervals
:ProperInterval
s
related
to
each
other
using
only
,
intervalMetBy
:intervalMetBy
,
intervalStartedBy
:intervalStartedBy
.
Many
other
interval
relationships
follow
logically
from
the
ones
shown
(for
example
'Neogene
Period'
intervalFinishedBy
:intervalFinishedBy
:
'Cenozoic
Era')
but
intervalDuring
:intervalDuring
these
the
ones
shown
are
sufficient
to
describe
the
full
topology.
topology.
For
example,
the
interval
known
as
the
'Phanerozoic
Eon'
is
a
:ProperInterval
described
as
follows:
geol:Phanerozoic
;
;
;
rdf:type :ProperInterval ;
:hasBeginning geol:BasePhanerozoic ;
:hasEnd geol:Present ;
:intervalFinishedBy geol:Cenozoic ;
;
;
;
:intervalMetBy geol:Proterozoic ;
:intervalStartedBy geol:Paleozoic ;
rdfs:label "Phanerozoic Eon"^^xsd:string ;
.
The
beginning
of
the
Phanerozoic
Eon
is
an
,
described
as
follows:
Instant
:Instant
geol:BasePhanerozoic
rdf:type :Instant ;
:inTimePosition [
rdf:type :TimePosition ;
:hasTRS <http:
:numericPosition ;
] ;
rdf:type :TimePosition ;
:hasTRS <http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime> ;
:numericPosition "541.0"^^:Number ;
] ;
rdfs:label "Base of Phanerozoic Eon"^^xsd:string ;
.
Note
that
the
position
of
this
is
specified
using
a
Instant
:Instant
,
which
is
a
numeric
value
relative
to
the
temporal
coordinate
system
indicated
as
the
value
of
the
TimePosition
:TimePosition
property.
hasTRS
:hasTRS
The RDF representation of this example is available here .
It may be useful to define specialized concepts by specialization.
The
following
example
illustrates
the
difference
between
using
For
example,
"January"
can
be
defined
as
a
a
subclass
of
DateTimeDescription
:DateTimeDescription
and
using
with
the
XML
datatype
dateTime
.
An
instant
restrictions
that
represents
the
start
of
a
meeting,
called
property
has
meetingStart
,
happens
at
10:30am
EST
on
01/01/2006
can
be
expressed
using
both
:unitType
unitMonth
and
property
inXSDDateTime
allValuesFrom
inDateTime
:month
in
OWL
as:
hasValue
of
1:
ex:January a owl:Class ; rdfs:subClassOf :DateTimeDescription ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :unitType owl:hasValue :unitMonth ] ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :month owl:hasValue --01 ; ] .
It
is
much
more
concise
to
use
the
XML
Schema
datatype
dateTime
.
Using
DateTimeDescription
more
information
can
For
example,
duration
"Year"
could
be
expressed,
such
defined
as
"week",
"day
of
week"
and
"day
a
subclass
of
year",
so
in
"DurationDescription"
with
the
example,
we
can
also
know
restrictions
that
01/01/2006
is
Sunday,
on
the
first
day
"years"
property
is
required
(with
"cardinality"
of
the
year,
1)
and
in
the
first
week
all
other
properties
(e.g.,
"hours",
"months")
should
not
be
present
(with
"cardinality"
of
the
year.
0):
ex:Year a owl:Class ; rdfs:subClassOf :DurationDescription ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :years ] ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 0 ; owl:onProperty :months ] ; ... rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 0 ; owl:onProperty :seconds ] .
The
namespace
“
tz-us
”
points
to
US
time
zone
data.
Moreover,
each
field
We
use
"cardinality
=
0"
instead
of
DateTimeDescription
is
separate
so
that
it
is
easier
to
extract
restricting
the
value
values
of
some
fields
for
the
later
use
and
easier
days,
etc.
to
0.
The
reason
about.
7.4
Temporal
precision
is
that
using
DateTimeDescription
vs
dateTime
vs
TimePosition
For
"cardinality
=
0"
means
all
those
properties/fields
(days,
etc.)
should
not
be
specified
(i.e.,
the
purposes
of
radiocarbon
dating
(which
granularity
is
the
technique
used
in
geological
age
determination
for
materials
up
"year"),
while
restricting
all
those
values
to
around
60,000
years
old)
1950
is
conventionally
defined
as
'the
Present'
[
RC-14
].
This
can
be
described
as
an
individual
:Instant
,
with
its
position
expressed
using
any
0
means
they
all
have
a
fixed
value
of
the
three
alternatives:
geol:Present
a :Instant ;
:inDateTime [
a :DateTimeDescription ;
:unitType :unitYear ;
:year ^^xsd:gYear ;
] ;
:inTimePosition [
a :TimePosition ;
:hasTRS <http:
:numericPosition ;
] ;
:inXSDDateTime ^^xsd:dateTime ;
rdfs:label ^^xsd:string ;
.
Expressed
using
:
DateTimeDescription
the
:
unitType
-
which
determines
the
precision
-
is
set
to:
unitYear
,
0
(i.e.,
x
years
0
months
0
days
...)
and
only
the
:
year
element
is
provided
in
the
value.
The
TRS
value
is
not
provided
explicitly,
as
it
is
fixed
in
the
ontology
description
to
<http://www.opengis.net/def/uom/ISO-8601/0/Gregorian>
.
In
the
:
TimePosition
variant,
the
TRS
granularity
is
given
as
<http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime>
actually
"second",
which
has
units
of
millions
of
years,
positive
backwards.
For
the
value
expressed
using
xsd:dateTime
the
position
within
the
year
is
set
arbitrarily
to
midnight
at
the
beginning
of
1st
January.
This
level
precision
is
strictly
spurious,
but
is
required
to
satisfy
not
the
lexical
pattern
correct
semantics
of
the
datatype.
"year".
The
use
of
different
temporal
reference
systems
for
the
same
absolute
time
is
illustrated
in
the
following
examples.
Abby's
birthday
Note
that
there
is
an
Instant
whose
position
may
be
expressed
using
the
conventional
XSD
dateTime
type
a
distinction
between
a
year
as
2001-05-23T08:20:00+08:00
:
ex:AbbyBirthday
a :Instant ;
:inDateTime ex:AbbyBirthdayHebrew ;
:inTimePosition ex:AbbyBirthdayUnix ;
rdfs:label ^^xsd:string ;
:inDateTime ex:AbbyBirthdayGregorian ;
:inXSDDateTime ^^xsd:dateTime ;
.
Using
the
DateTimeDescription
class,
the
elements
of
the
date
a
duration
and
time
using
the
Gregorian
Calendar
are
split
out
into
separate
properties:
ex:AbbyBirthdayGregorian
a :DateTimeDescription ;
:day ^^xsd:gDay ;
:dayOfWeek :Wednesday ;
:hour ^^xsd:nonNegativeInteger ;
:minute ^^xsd:nonNegativeInteger ;
:month ^^xsd:gMonth ;
:timeZone [
a tzont:TimeZone ;
tzont:GMToffset ;
tzont:name ;
] ;
:unitType :unitMinute ;
:year ^^xsd:gYear ;
.
The
GeneralDateTimeDescription
class
may
be
used
to
express
the
same
date
using
the
Hebrew
calendar:
ex:AbbyBirthdayHebrew
a :GeneralDateTimeDescription ;
:day ^^:generalDay ;
:hasTRS <http:
:month ^^:generalMonth ;
:year ^^:generalYear ;
:unitType :unitDay ;
.
a
calendar
year.
The
TimePosition
class
may
be
used
year
from
December
22,
2006
to
express
the
same
position
on
December
21,
2007
is
the
Unix
time
scale
(i.e.
former
but
not
the
number
of
seconds
since
1st
January
1970):
ex:AbbyBirthdayUnix
a :TimePosition ;
:hasTRS <http:
:numericPosition ;
rdfs:label ^^xsd:string ;
.
The
RDF
representation
of
this
example
is
available
here
.
latter.
Suppose
someone
has
a
telecon
scheduled
for
6:00pm
EST
on
November
5,
2006.
You
would
like
to
make
an
appointment
with
him
for
2:00pm
PST
on
the
same
day,
and
expect
the
meeting
to
last
45
minutes.
minutes.
Will
there
be
an
overlap?
In this use case we can specify the facts about the telecon and the meeting using our ontology in OWL that will allow a temporal reasoner to determine whether there is a conflict:
;
.
;
;
.
ex:telecon
a :Interval ;
:hasBeginning ex:teleconStart .
;
"2006 .
ex:meeting
a :Interval ;
:hasBeginning ex:meetingStart ;
:hasDurationDescription ex:meetingDuration .
;
"2006 .
ex:teleconStart
a :Instant ;
:inXSDDateTime "2006-11-05T18:00:00-5:00"^^xsd:dateTimeStamp .
;
45 .
ex:meetingStart
a :Instant ;
:inXSDDateTime "2006-11-05T14:00:00-8:00"^^xsd:dateTimeStamp .
ex:meetingDuration
a :DurationDescription ;
:minutes 45 .
The
telecon
and
the
meeting
are
defined
as
intervals.
is
used
for
specifying
the
start
times
of
the
meetings.
The
datetimes
are
specified
using
hasBeginning
:hasBeginning
.
The
duration
of
the
meeting
is
specified
using
the
inXSDDateTime
:inXSDDateTime
duration
description
:DurationDescription
class.
Congo.com
and
Bravo
Air
are
examples
from
the
OWL-S
0.9
draft
release
[
OWL-S
].
Congo.com
is
a
fictitious
book-selling
service
site,
and
Bravo
Air
is
a
fictitious
airline-ticketing
service
site.
These
examples
demonstrate
how
the
time
ontology
can
be
used
to
support
OWL-S,
including
use
cases
for
defining
input
parameters
and
(conditional)
output
parameters.
parameters.
In
the
profile
of
the
Congo.com
example
(i.e.
CongoProfile.owl),
for
example,
our
time
ontology
is
currently
used
for
describing
the
input
parameter
CreditCardExpirationDate
:
profile:CreditCardExpirationDate
;
;
;
.
a profile:ParameterDescription ;
profile:parameterName ex:creditCardExpirationDate ;
profile:restrictedTo :Instant ;
profile:referTo congoProcess:creditCardExpirationDate .
The
namespace
“time”
points
to
the
location
of
the
OWL
code
for
the
time
ontology.
In
this
example
is
used
to
describe
Instant
:Instant
CreditCardExpirationDate
,
because
the
expiration
date
is
actually
an
instant
--
the
midnight,
of
the
day
the
credit
card
expires.
In
the
Bravo
Air
example,
our
time
ontology
can
be
used
to
describe
the
existing
input
parameters,
DepartureDate
and
ArrivalDate
.
We
will
change
this
to
the
more
appropriate
DepartureTime
and
ArrivalTime
.
We
can
define
DepartureTime
in
the
profile
of
the
Bravo
Air
example
(i.e.
BravoAirProfile.owl)
as:
profile:DepartureTime
;
;
;
.
a profile:ParameterDescription ;
profile:parameterName ex:DepartureTime ;
profile:restrictedTo :Instant ;
profile:referTo ba_process:outboundDate_In .
DepartureTime
is
defined
as
.
With
this
definition,
as
we
discussed
in
the
previous
datetime
description
section,
an
instance
of
Instant
:Instant
DepartureTime
can
has
either
an
property/relation
pointing
to
a
specific
value
of
XML
Schema
datatype
dateTime,
say
2006-01-01T10:30:00-5:00,
or
an
inXSDDateTime
:inXSDDateTime
object-property/relation
pointing
to
an
instance
of
inDateTime
:inDateTime
class
specifying
a
specific
time,
say
10:30am
EST
on
01/01/2006,
Sunday.
It
would
be
the
user’s
decision
to
define
the
time
in
either
way
based
on
the
trade-offs
discussed
in
the
previous
section.
DateTimeDescription
:DateTimeDescription
In fact, there is much more that our time ontology can do to support OWL-S. In the Congo.com and Bravo Air examples, the time ontology is not used for any output parameters. However, in the real world many service outputs are time-related. For example, in the Congo.com example we can add two outputs that are very common in real world book-selling sites: process time and delivery duration.
ProcessTime
output
parameter
ProcessTime
is
a
conditional
output
parameter
that
specifies
how
long
before
the
book
will
be
ready
for
delivery,
say,
24
hours,
which
depends
on
whether
the
book
is
in
stock.
In
this
use
case,
the
process
time
is
returned
only
if
the
book
is
in
stock.
It
can
be
defined
in
the
process
model
of
the
Congo.com
example
(i.e.
CongoProcess.owl)
as:
:ProcessTime a owl:Class ; rdfs:subClassOf :Interval .ex:ProcessTime a owl:Class ; rdfs:subClassOf :Interval ; .:fullCongoBuyProcessTime a rdf:Property ; rdfs:subPropertyOf process:output ; rdfs:domain :FullCongoBuy ; rdfs:range [ a owl:Class ; rdfs:subClassOf process:ConditionalOutput ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :BookInStock ; owl:onProperty process:coCondition ] ;ex:fullCongoBuyProcessTime a rdf:Property ; rdfs:subPropertyOf process:output ; rdfs:domain ex:FullCongoBuy ; rdfs:range [ a owl:Class ; rdfs:subClassOf process:ConditionalOutput ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:BookInStock ; owl:onProperty process:coCondition ] ;rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :ProcessTime ; owl:onProperty process:coOutput ] .] ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:ProcessTime ; owl:onProperty process:coOutput ] ; .
ProcessTime
is
defined
as
an
interval,
rather
than
a
duration.
As
discussed
previously,
in
our
time
ontology
durations
are
properties
of
intervals.
Thus
to
talk
about
a
duration,
i.e.
a
quantity
of
time,
an
interval
must
be
defined
first.
This
approach
may
look
roundabout
at
first
glance.
However,
the
process
time
is
not
purely
a
quantity
of
time;
it
has
a
location
on
the
time
line.
The
beginning
of
the
process
time
is
the
time
the
user
places
the
order,
and
the
end
of
the
process
time
is
the
time
the
order
is
shipped
out.
An
advantage
of
defining
ProcessTime
as
an
interval
is
that
if
the
relationship
among
the
order
time,
the
shipping
time,
and
the
process
time
is
known,
any
one
of
them
(e.g.
the
shipping
time)
can
be
computed
from
the
other
two
(e.g.
the
order
time
and
the
process
time)
by
temporal
arithmetic.
DeliveryDuration
output
parameter
DeliveryDuration
is
a
conditional
output
parameter
that
specifies
how
long
it
will
take
for
the
customer
to
receive
the
book
after
it
is
shipped
out,
which
depends
on
the
delivery
type
the
customer
selects.
As
defined
in
the
process
model
of
the
Congo.com
example
(i.e.
CongoProcess.owl),
the
current
delivery
types
are
FedExOneDay,
FedEx2-3day,
UPS,
and
OrdinaryMail.
To
add
this
output
parameter
may
seem
similar
to
the
above
ProcessTime
example.
However,
since
an
instance
of
Condition
is
a
logical
formula
that
evaluates
to
true
or
false
(see
the
comment
with
the
definition
of
Condition
[
PR-OS
]),
DeliveryType
cannot
be
directly
used
as
a
condition
to
determine
the
delivery
duration.
Thus
one
property
and
one
condition
are
defined
for
each
delivery
type.
DeliveryDuration
is
defined
with
two
boundaries:
one
minDeliveryDuration
and
one
maxDeliveryDuration
.
For
example,
an
order
with
the
FedEx2-3day
delivery
type
takes
2
to
3
days,
so
its
min
delivery
duration
is
2
days,
and
its
max
delivery
duration
is
3
days.
For
the
delivery
duration
of
the
order
with
FedExOneDay
delivery
type,
the
min
and
max
delivery
duration
will
both
be
1
day.
We
can
define
DeliveryDuration
in
the
process
model
of
the
Congo.com
example
(i.e.
CongoProcess.owl)
as:
:DeliveryDuration a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :maxDeliveryDuration ] ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty :minDeliveryDuration ] .ex:DeliveryDuration a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty ex:maxDeliveryDuration ] ; rdfs:subClassOf [ a owl:Restriction ; owl:cardinality 1 ; owl:onProperty ex:minDeliveryDuration ] .:maxDeliveryDuration a rdf:Property ; rdfs:domain :DeliveryDuration ; rdfs:range :Interval .ex:maxDeliveryDuration a rdf:Property ; rdfs:domain ex:DeliveryDuration ; rdfs:range :Interval .:minDeliveryDuration a rdf:Property ; rdfs:domain :DeliveryDuration ; rdfs:range :Interval .ex:minDeliveryDuration a rdf:Property ; rdfs:domain ex:DeliveryDuration ; rdfs:range :Interval .
Both
minDeliveryDuration
and
maxDeliveryDuration
are
defined
as
properties
of
DeliveryDuration
.
For
the
same
reason
discussed
for
the
process
time
example,
both
properties
use
Interval
as
their
ranges.
The
cardinality
of
1
for
both
properties
in
the
definition
of
DeliveryDuration
indicates
that
an
instance
of
DeliveryDuration
must
have
one
and
only
one
property
value
for
minDeliveryDuration
and
maxDeliveryDuration
respectively.
For
example,
in
order
to
define
delivery
duration
for
FedEx2-3day,
we
have
to
first
define
a
condition
of
FedEx2-3day
being
selected:
;
.
ex:FedEx2-3dayCondition
a owl:Class ;
rdfs:subClassOf process:Condition .
Then
we
define
an
output
property,
called
deliverySelectFedEx2-3day
that
is
conditional
on
FedEx2-3dayCondition
defined
above:
:deliverySelectFedEx2-3day a rdf:Property ; rdfs:subPropertyOf process:output ; rdfs:domain :SpecifyDeliveryDetails ; rdfs:range [ a owl:Class ; rdfs:subClassOf process:ConditionalOutput ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :FedEx2-3dayDuration ; owl:onProperty process:coOutput ] ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :FedEx2-3dayCondition ; owl:onProperty process:coCondition ] .ex:deliverySelectFedEx2-3day a rdf:Property ; rdfs:subPropertyOf process:output ; rdfs:domain ex:SpecifyDeliveryDetails ; rdfs:range [ a owl:Class ; rdfs:subClassOf process:ConditionalOutput ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:FedEx2-3dayDuration ; owl:onProperty process:coOutput ] ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:FedEx2-3dayCondition ; owl:onProperty process:coCondition ] ; ] .
This
definition
says
that
deliverySelectFedEx2-3day
is
a
conditional
output,
and
if
FedEx2-3dayCondition
is
true,
an
instance
of
FedEx2-3dayDuration
class
will
be
the
output.
FedEx2-3dayDuration
is
not
defined
yet.
In
order
to
define
it,
we
have
to
define
its
min
delivery
duration,
i.e.
2
days,
and
max
delivery
duration,
i.e.
3
days.
Since
the
range
of
minDeliveryDuration
and
maxDeliveryDuration
is
,
intervals
with
specific
durations
need
to
be
created
first.
For
Interval
:Interval
FedEx2-3dayDuration
,
we
need
to
define
Interval2Days
and
Interval3Days
first
as
follows:
:Interval2Days a owl:Class ; rdfs:subClassOf :Interval ; owl:subClassOf [ a owl:Restriction ; owl:hasValue P2D ; owl:onProperty :durationDescriptionDataType ] .ex:Interval2Days a owl:Class ; rdfs:subClassOf :Interval ; rdfs:subClassOf [ a owl:Restriction ; owl:hasValue P2D ; owl:onProperty :durationDescriptionDataType ] .:Interval3Days a owl:Class ; rdfs:subClassOf :Interval ; owl:subClassOf [ a owl:Restriction ; owl:hasValue P3D ; owl:onProperty :durationDescriptionDataType ] .ex:Interval3Days a owl:Class ; rdfs:subClassOf :Interval ; rdfs:subClassOf [ a owl:Restriction ; owl:hasValue P3D ; owl:onProperty :durationDescriptionDataType ] .
These
two
definitions
use
durationDescriptionDataType
,
a
relatively
simpler
duration
property
of
using
the
XML
Schmea
datatype
Interval
:Interval
as
its
range.
duration
xsd:duration
P2D
and
P3D
are
values
of
the
XML
Schema
datatype
,
meaning
2
days
and
3
days.
duration
xsd:duration
Finally,
FedEx2-3dayDuration
restricts
the
value
of
minDeliveryDuration
and
maxDeliveryDuration
to
class
Interval2Days
and
Interval3Days
respectively
as
follows:
:FedEx2-3dayDuration a owl:Class ; rdfs:subClassOf :DeliveryDuration ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :Interval3Days ; owl:onProperty :maxDeliveryDuration ] ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom :Interval2Days ; owl:onProperty :minDeliveryDuration ] .ex:FedEx2-3dayDuration a owl:Class ; rdfs:subClassOf ex:DeliveryDuration ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:Interval3Days ; owl:onProperty ex:maxDeliveryDuration ] ; rdfs:subClassOf [ a owl:Restriction ; owl:allValuesFrom ex:Interval2Days ; owl:onProperty ex:minDeliveryDuration ] .
Properties to output delivery durations when the user selects other delivery types (FedExOneDay, UPS, and OrdinaryMail) can be defined similarly.
:TemporalEntity
:Interval
:ProperInterval
:DateTimeInterval
:Instant
:TRS
:TimePosition
:GeneralDateTimeDescription
:DateTimeDescription
:TimeZone
:TemporalUnit
:Duration
:GeneralDurationDescription
:DayOfWeek
This
section
unaltered
from
[
:generalDay
owl-time-20060927
:generalMonth
].
:generalYear
:Number
This
version
of
jurisdictions
(Region,
PoliticalRegion,
Country,
State,
Reservation,
County,
City)
which
does
not
cover
all
international
practice.
It
refers
to
GMT,
rather
than
UTC.
It
has
fixed
dates
for
daylight
savings
start
and
end,
else
uses
a
time-sequence
ontology
which
is
not
provided.
Appears
to
need
more
work.
We
have
OWL-Time
was
developed
a
time
zone
resource
in
OWL
for
the
entire
world,
including
three
parts:
the
time
zone
ontology
file
,
Spatial
Data
on
the
US
time
zone
instance
file
,
Web
Working
Group
(a
joint
activity
involving
W3C
and
the
world
time
zone
instance
file
.
Open
Geospatial
Consortium).
The
time
zone
ontology
links
a
preliminary
geographic
ontology
with
a
time
ontology.
It
defines
Ontology
is
based
on
the
vocabulary
about
regions,
political
regions
(countries,
states,
counties,
reservations,
and
cities),
time
zones,
daylight
saving
policies,
and
one
described
in
the
relationships
between
these
concepts.
Its
instances
also
link
to
other
existing
data
on
2006
Draft
are
[
OWL-T
]
though
the
Web,
such
document
has
been
completely
re-written.
The
principal
technical
changes
are
as
FIPS
55
county
instances
[
follows:
:GeneralDateTimeDescription
],
and
ISO-C
:GeneralDurationDescription
].
It
can
handle
all
the
usual
time
zone
and
daylight
savings
cases.
For
example,
Los
Angles
uses
PST,
are
generalizations
of
the
B.1
Use
case
examples
:TimePosition
Suppose
someone
has
and
:Duration
are
new
classes
to
enable
position
or
duration
to
be
described
using
a
:hasTRS
enables
time
values
to
:TRS
:Year
and
:January
are
deprecated,
and
:TimeZone
in
the
We
take
PoliticalRegion
to
be
a
subclass
A
number
of
Region
with
requirements
relating
to
Time
were
identified
in
the
following
properties:
Spatial
Data
on
the
Web
Use
Cases
&
Requirements
.
This
can
be
defined
in
OWL
as:
The
following
notes
indicate
where
these
have
been
addressed.
(TBC)
(Was
local
Issue
1)
Most
of
xsd:date.
In
the
current
instance
files,
different
daylight
saving
policies
were
only
properties
defined
for
year
2006
as
instances
of
EnumeratedDaylightSavingsPolicy
,
e.g.
USA2006DLS
for
in
the
United
States,
original
ontology
have
global
constraints
on
the
domain
and
range.
If
the
EU2006DLS
rdfs:domain
for
were
left
unspecified,
the
European
Union.
Alternatively,
a
temporal
aggregates
ontology
in
OWL-Time
can
properties
could
be
used
to
describe
the
daylight
saving
policies.
For
example,
more
widely
without
undesirable
entailments.
Their
use
in
the
US
daylight
saving
starts
on
"the
first
Sunday
context
of
every
April",
which
can
be
expressed
the
classes
in
OWL
as:
the
ontology
is
adequately
controlled
through
guarded
restrictions
(local
cardinality
constraints)
-
superseded
by
ISSUE-65
(Was
local
Issue
2)
The
Time
ontology
is
concerned
only
with
formalizing
temporal
sequence.
In
order
intervals
and
instants,
and
does
not
include
any
predicates
to
describe
this
two-layered
temporal
sequence
("the
first
Sunday"
of
"every
April"),
the
outside
layer
("every
April"),
i.e.
the
context
tie
temporal
sequence
(
tseq-everyApril
),
needs
objects
to
be
defined
first.
This
context
temporal
sequence
also
has
its
own
hasTemporalAggregateDescription
property
spatial
entities
or
features,
or
other
things.
The
editors
note
that
points
to
everyApril
which
describes
predicates
that
it
is
the
every
4th
(
hasithTemporalUnit
concern
temporal
behaviour
and
properties
will
usually
be
part
of
4)
month
(
hasTemporalUnit
an
application
or
associated
with
a
community
of
unitMonth
).
The
desired
temporal
sequence
is
then
defined
practice.
Nevertheless,
there
may
be
some
generic
predicates
that
could
be
conveniently
provided
as
"the
first
(
hasPosition
part
of
1)
Sunday
the
generic
time
ontology.
Some
may
already
exist
in
the
ontology
(
,
hasithTemporalUnit
of
7
and
:before
,
hasTemporalUnit
of
:after
,
unitDayOfWeek
)
of
every
April
(
:hasEnd
,
hasContextTemporalSeq
of
:hasBeginning
tseq-everyApril
:intervalEquals
and
)
but
their
hasContextTemporalUnit
rdfs:domain
of
is
or
unitMonth
)".
For
details
about
the
temporal
aggregates
ontology
and
its
use
case
examples,
please
see
[
PA-05
:TemporalEntity
],
[
,
so
this
may
need
to
be
generalized
to
avoid
inappropriate
entailments.
Else
predicates
with
similar
names
could
be
provided
for
linking
to
other
entities.
PH-04
:ProperInterval
].
The
SDWWG
requirement
5.56
Valid
time
]
relates
to
ISSUE-65
.
(Was
local
Issue
3)
Temporal
vagueness
requirement.
Extended
Data/Time
Format
(EDTF)
is
a
location,
e.g.
a
city,
detailed
proposal
for
how
to
encode
temporal
vagueness,
and
some
other
concerns,
by
extending
the
output
will
be
its
current
time
offset,
say
-6
hours,
from
the
Greenwich
Mean
Time
(GMT).
xsd:dateTime
syntax
.
The
ontology
editors
consider
that
would
be
used
as
follows:
given
an
input
location,
we
first
find
in
the
ontology
the
lowest-level
political
region
containing
this
location,
say
a
county,
then
go
up
along
the
political
region
hierarchy
based
on
the
hasParentRegion
property
to
the
top
of
the
hierarchy,
usually
a
country.
Along
the
path
to
wrong
direction
since
it
would
make
the
top,
we
get
encoding
inconsistent
with
all
XSD-based
processors.
On
the
available
information
from
each
node
(region)
other
hand,
specific
RDF
properties
matching
the
ones
proposed
in
order
EDTF
could
be
used
to
calculate
the
time
offset
from
the
GMT.
The
information
includes
the
time
zone
this
location
is
in,
whether
make
it
uses
Daylight
Savings
(DLS)
time,
and
if
amenable
to
RDF
reasoning.
However,
it
does,
what
could
be
done
in
a
separate
namespace.
Note
that
some
of
the
start
and
end
dates
are.
However,
flexible
inputs
and
more
efficiency
concerns
in
EDTF
are
supported
by
using
the
exceptionalRegion
and
timeZonePart
properties,
i.e.
the
location
input
does
not
have
already
accommodated
in
OWL-Time
(e.g.
'unspecified'
appears
to
be
as
detailed
as
the
lowest-level
political
region,
especially
because
usually
only
require
the
information
about
what
state
it
is
in
would
be
enough
timeUnit
to
calculate
the
time
offset
from
the
GMT
for
the
input
location.
be
chosen
appropriately).
The
SDWWG
requirement
5.49
Temporal
vagueness
relates
to
its
state
and
see
whether
we
can
find
all
the
information
we
need
there,
i.e.
time
zone
and
daylight
savings
information.
If
the
state
doesn't
have
any
ISSUE-26
.
The
classes
,
exceptionalRegion
:GeneralDateTimeDescription
:DateTimeDescription
,
:TimePosition
’s,
then
we
don't
need
any
more
inputs
for
this
location,
and
can
safely
go
up
along
the
political
region
hierarchy
to
the
top
of
the
hierarchy,
e.g.
address
the
country
US,
'date'
and
get
all
the
information
we
need
along
the
way
to
calculate
the
time
offset
'time'
requirement
from
the
GMT
for
this
location.
If
the
state
does
have
any
5.7
Date,
time
and
duration
The
classes
,
exceptionalRegion
’s,
however,
we
have
to
check
each
exceptional
region
to
see
whether
this
location
is
in
it
or
not,
at
this
checking
phase,
more
detailed
information
about
this
location
may
be
needed,
i.e.
which
county/city/reservation
it
is
in.
If
it's
in
an
exceptional
county
that
further
has
:GeneralDurationDescription
,
timeZonePart
:DurationDescription
:Duration
’s,
then
even
more
detailed
information
is
needed
from
address
the
input,
i.e.
which
'duration'
requirement
from
5.7
Date,
time
zone
part
the
location
is
in
within
this
county.
When
reaching
a
sub-region
with
no
and
duration
The
class
exceptionalRegion
:TRS
’s
or
and
property
timeZonePart
:hasTRS
’s,
we
know
for
sure
that
no
more
input
location
information
is
needed
and
it's
safe
to
go
up
along
the
political
region
hierarchy
to
the
top,
and
get
all
the
information
we
need
to
calculate
addresses
the
time
offset
following
requirements
from
the
GMT
for
this
location.
For
example,
suppose
the
input
location
is
a
location
in
West
Wendover,
Nevada,
but
at
first
we
only
know
it's
in
Nevada
(please
see
the
OWL
code
[
in
the
previous
section
SDWWG:
5.9
Different
time
models
,
5.48
Temporal
reference
system
,
5.28
Nominal
temporal
references
.
(Was
local
Issue
4)
Past,
present
future
-
this
location
in?
Say
we
get
West
Wendover
City.
Since
it
matches
the
exceptional
region,
we
then
go
to
the
West
Wendover
City
instance
appears
to
get
its
time
zone
information,
which
is
the
Mountain
time
zone.
Since
there
is
no
exceptionalRegion
’s
or
timeZonePart
’s
already
be
supported
using
capabilities
in
the
West
Wendover
City
instance,
it's
now
safe
for
us
to
go
up
along
the
hierarchy
OWL-Time,
but
needs
to
the
top,
the
United
States.
Along
the
path,
at
Nevada
State
we
learn
this
location
uses
DLS
time,
then
at
its
parent
region,
the
US,
we
learn
the
DLS
policy
used
is
USA2006DLS
which
specifies
the
start
date
of
the
DLS
in
2006
is
04/02/2006
and
the
end
date
is
10/29/2006.
Based
on
our
current
time,
e.g.
1:50pm
on
09/06/2006,
we
know
the
current
time
offset
from
the
GMT
at
this
location
is
-7
hours.
be
verified.
The
editors
would
like
SDWWG
requirement
5.25
Multilingual
support
relates
to
thank
Jerry
Hobbs
and
Feng
Pan
for
producing
the
original
draft.
documentation
of
the
ontology.
The editors would like to thank Jerry Hobbs and Feng Pan for producing the original draft.