search

streamreasoning / RSP-QL

A home of RSP-QL syntax and semantics discussion
Apache License 2.0
18 stars 14 forks source link

Temporal Entities and OWL Time #25

Open greenTara opened 8 years ago

greenTara commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

lisp commented 8 years ago

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 commented 8 years ago

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:

Older temporal ontologies include:

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 (https://github.com/streamreasoning/RSP-QL/pull/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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/streamreasoning/RSP-QL/issues/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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

greenTara commented 8 years ago

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 commented 8 years ago

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

greenTara commented 8 years ago

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

lisp commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/streamreasoning/RSP-QL/issues/25#issuecomment-187722955 .

Sent from my Android phone. Please excuse my brevity.

greenTara commented 8 years ago

@Daniele - ok, let's start an issue (https://github.com/streamreasoning/RSP-QL/issues/55) where profiles can be discussed.

lisp commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@lisp regarding documentation of the "linked-list" usecase, and profile, I have opened an issue for this: https://github.com/streamreasoning/RSP-QL/issues/56

danhlephuoc commented 8 years ago

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