Temporal Entities and OWL Time

[greenTara]

There is an ambiguity or inconsistency in the Abstract Syntax and Semantics document regarding temporal entities. The section "Temporal Entities" says the specification is neutral in regard to temporal ontologies. The section "Instants and Intervals" references the OWL Time Ontology.

[jpcik]

While it could be neutral, in the end we propose to use the OWL time Ontology. It is probably useful to say why we think this is a good choice: e.g. it has the instants/intervals we need, it is already in the realm of RDF, and it is sort of standard

[greenTara]

There is really a lot of work in involved in specifying what might constitute an appropriate set of temporal entities while remaining neutral about a temporal ontology. So if you are going to end up using the OWL Time ontology in the end, why go to the trouble of allowing others?

BTW, there are some other very good temporal ontologies out there (e.g. http://www.omg.org/spec/DTV/1.0/). I thought this was the reason for remaining neutral about the temporal ontology.

[greenTara]

Further point - The value space of XSD temporal literals is not a subclass of owltime:TemporalEntity, as far as I can tell. So even if we restrict ourselves to the OWL Time ontology, I don't think it is correct to say that timestamps are owltime:TemporalEntities, assuming we want to allow these xsd:dateTime values as timestamps.

[jpcik]

I wouldn't just restrict to OWL time. I just say it can be a good model. So I would think that the reference to the OWL time could be changed so that we say it is a good example. And we could add other time conceptualizations as well.

[greenTara]

Here is a useful reference http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf

[lisp]

There is really a lot of work in involved in specifying what might constitute an appropriate set of temporal entities while remaining neutral about a temporal ontology. So if you are going to end up using the OWL Time ontology in the end, why go to the trouble of allowing others?

it would be helpful to call out the ontologies which are allowed and to define the comparison and/or promotion operators why apply between the respective domains in order to that the merge and union operators are defined for those domains in combinations.

[greenTara]

I believe the idea is not to limit the temporal ontologies that are allowed in general, but for each timestamp predicate to choose exactly one temporal ontology, and more precisely to specify the range (in the RDFS sense) of each timestamp predicate to be a particular class within a particular temporal ontology.

Here are some different possible ranges for timestamp predicates:

• OWL-TIME is linear and continuous. Within OWL-TIME, there are still several choices of timestamp range:
  • owl:TemporalEntity: subclasses instants and intervals
  • NOT owl:TemporalEntity : the XSD temporal values spaces, xsd:dateTime, xsd:date
• OMG Date-Time http://www.omg.org/spec/DTV/1.0/ The OMG temporal model is linear and continuous, like OWL-TIME, so conversion is possible. Unlike OWL-TIME, there is a more rigorous treatment of the concepts of time coordinates (like xsd:dateTime values) versus time periods (like owl:TemporalEntity). Also OMG Date-Time solves the ambiguity of xsd:duration values like "3M" (three months).

Older temporal ontologies include:

• http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTemporalOntology
• http://dl.acm.org/citation.cfm?id=1741341
• http://stl.mie.utoronto.ca/publications/psl-chapter.pdf
  A more general discussion of time is in http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf
  There are certain kinds of temporal topology, e.g. branching time, that are not represented in the above ontologies. Leaving things open to any temporal ontology allows RDF streams to accommodate future developments in temporal ontologies, while requiring each timestamp predicate to specify its range enables a clear definition of the temporal order for that predicate.

One thing that needs to be made clear is that alignment between different temporal ontologies is out of scope for RSP-QL. This is not our job, anymore than it is our job to create temporal ontologies.

Second, some clarification on timestamp predicates. The idea is that a timestamp predicate specifies its range (as in RDFS) to be a particular class of temporal entities, and also specifies the temporal order on that range. For example the PROV-O property prov:generatedAt has range xsd:dateTime. If we will use that as a timestamp predicate, we (RSP-QL community) must specify the partial order (in the value space) that will determine if a particular sequence of timestamped graphs is an RDF stream. This should not be too hard, but it must be explicitly stated because it is not specified by the XSD Datatypes specification.

Third, regarding merge and union. There is a pull request (#39) that is intended to better define merge and union. Briefly, these are defined as relations between RDF streams rather than functional operators in the usual sense. The intention is to separate the concerns regarding the syntactic joining of the elements of two streams from the semantic conditions that determine whether a sequence of timestamped graphs is an RDF stream. Please refer to that for more details on the definition of merge and union. However, in regard to aligning between different temporal ontologies: If two timestamped graphs have timestamps coming from different temporal ontologies, one of two things must be happening. (1) They have different timestamp predicates. That means they can occur in arbitrary relative order within the stream. (2) They have the same timestamp predicate. In this case, the timestamp predicate must explicitly allow entities from the two ontologies in the range of the predicate. In that case the alignment between the two ontologies must be declared when the partial order for this timestamp predicate is defined.

Finally, I would argue against timestamp predicates of the second kind. Rather than mixing temporal ontologies together for a single predicate, it would be better, IMHO, to perform a translation (through an RSP-QL query) from one temporal ontology to another. That is, if one stream uses prov:generatedAt and a second stream uses a different timestamp predicate with the same "meaning" but different timestamp class, then one stream should be converted to the other timestamp predicate before merging.

[lisp]

One thing that needs to be made clear is that alignment between different temporal ontologies is out of scope for RSP-QL. This is not our job, anymore than it is our job to create temporal ontologies.
Finally, I would argue against timestamp predicates of the second kind. Rather than mixing temporal ontologies together for a single predicate, it would be better, IMHO, to perform a translation (through an RSP-QL query) from one temporal ontology to another. That is, if one stream uses prov:generatedAt and a second stream uses a different timestamp predicate with the same "meaning" but different timestamp class, then one stream should be converted to the other timestamp predicate before merging.

this is exactly the position which my comment intends to question. while the approach simplifies the formal model, but introduces a step which any production implementation would likely treat as gratuitous, to be replaced by a mechanism which follows the implications of promotion or transformation rules between the respective domains. rather than require the explicit transformation through a query, it would be better to sanction a means to declare, for example, that the values of an xsd:dateTime domain are comparable with the values associated with the time:inXSDDateTime predicate of an time:Instant domain.

[greenTara]

We haven't gotten into these details yet about how to specify the partial order that is associated with a timestamp predicate. It is actually the subject of a different issue #26. Lets move the discussion of defining timestamp predicate range and comparing temporal entities to that issue, and leave this issue to be about what temporal entities are allowed in general.

The key question for this issue was about committing to OWL-TIME exclusively versus allowing other temporal ontologies. So far, no one has argued in favor of committing to OWL-TIME exclusively.

[beta2k]

Just from a pragramic point of view: what would be a disadvantage if we fully commit to OWL-TIME? okay, it would make out approach dependent from OWL-TIME which we may want to avoid. However, if it's possible to cover all the cases we need with OWL-TIME then I think there's nothing against committing to it..

[lisp]

what would be a disadvantage if we fully commit to OWL-TIME?

the representation is more complex than would be required by some use cases.

[jpcik]

As far as i understand, if OWL time is used, the graph timestamps would be something like this: :g1 :p :t1. :t1 :inXSDDateTime 2016-01-01T10:30:00-1:00. While in some use cases you would like to just use the xsd datetime value instead of the OWL-Time instant :t1.

[lisp]

yes, that is the consequence. an extra statement and, effectively, an extra join for all processing steps.

while the owl time schema would facilitate presentations and interfaces, in that can afford direct access to the constituent properties through an associated time:DateTimeDescription and that value, in turn, includes a property for the unit, temporal stream processing would most likely depend on some internal representation for the associated :inXSDDateTime value, in which context the rest of the content would be redundant.

[greenTara]

Here is another ontology with some temporal aspects to it: http://www.heppnetz.de/ontologies/goodrelations/v1.html#OpeningHoursSpecification

[greenTara]

One thing the the temporal entities of OWL-TIME does allow, that is not possible with xsd:dateTime, is to refer to some temporal entity for which you don't have complete information, but you might know it is before or after certain other temporal entities. This is a usecase that has been raised by @kiat .

[lisp]

is it included in https://www.w3.org/community/rsp/wiki/Use_cases ?

[greenTara]

Not there (yet). It is related to this https://www.w3.org/community/rsp/wiki/Semantic_CEP

[lisp]

Not there (yet). It is related to this https://www.w3.org/community/rsp/wiki/Semantic_CEP

for the moment, mostly, to be defined.
is the issue recorded anywhere else?

[greenTara]

Statements like "temporal stream processing would most likely depend on some internal representation for the associated :inXSDDateTime value, in which context the rest of the content would be redundant." concern me. I hope that this effort is not leading to temporal stream proccessing that ignores the semantics of the stream, where the "rest of the content" is not at all redundant. For example, the identifier (IRI or blank node) of the temporal entity may be used elsewhere in that timestamped graph, or in another timestamped graph in the stream.

I think it would be helpful to define some more subclasses (profiles) of RDF streams that have the characteristics necessary for certain processing (= reasoning) methods, and avoid making general assumptions about how stream processing will be done.

[dellaglio]

I totally agree on both the points of the last paragraph of Tara's mail, on
identifying stream profiles and on focusing on what processing does rather
than how it is done.

Daniele

Il giorno Mar 23 Feb 2016 15:39 Tara Athan notifications@github.com ha
scritto:

Statements like "temporal stream processing would most likely depend on
some internal representation for the associated :inXSDDateTime value, in
which context the rest of the content would be redundant." concern me. I
hope that this effort is not leading to temporal stream proccessing that
ignores the semantics of the stream, where the "rest of the content" is not
at all redundant. For example, the identifier (IRI or blank node) of the
temporal entity may be used elsewhere in that timestamped graph, or in
another timestamped graph in the stream.

I think it would be helpful to define some more subclasses (profiles) of
RDF streams that have the characteristics necessary for certain processing
(= reasoning) methods, and avoid making general assumptions about how
stream processing will be done.

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

Sent from my Android phone. Please excuse my brevity.

[greenTara]

@Daniele - ok, let's start an issue (#55) where profiles can be discussed.

[lisp]

Statements like "temporal stream processing would most likely depend on some internal representation for the associated :inXSDDateTime value, in which context the rest of the content would be redundant." concern me.

if you take the statement out of context, rather than as a continued response to the the question

Just from a pragramic point of view: what would be a disadvantage if we fully commit to OWL-TIME?

it really should not concern you as it does not have any value at all.

[greenTara]

@lisp I didn't mean to take your statement out of context, but I think I did misunderstand it. If you are considering a case when the stream uses time instants just as an intermediary to get to an xsd:dateTime value, and never for anything else, then I agree the time instants are redundant.

[greenTara]

More information on time ontologies: (from Michael Gruninger of University of Toronto)
There are many (approx. 87) different time ontologies in the Common Logic Ontology Repository (COLORE),
which can be found at colore.oor.net.

The relevant hierarchies are
combined_time
timepoints
periods
approximate_point
interval_meeting
owltime_instants and owltime_interval

[greenTara]

@lisp regarding documentation of the "linked-list" usecase, and profile, I have opened an issue for this: #56

[danhlephuoc]

Please consider the latest effort of standardising Time Ontology at http://w3c.github.io/sdw/time/