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.