Identify a time vocabulary about rsp-ql HOT 46 OPEN

Yes, as you can see at the link pointing to the group's charter, section 3, the idea is to standardize the Time Ontology in OWL (http://www.w3.org/TR/owl-time/).

from rsp-ql.

That ontology does not seem to have the types of property that we are looking for, e.g. time that a sensor made a reading or time that the data arrived at the processing engine.

from rsp-ql.

what if we create our own micro-vocab for that? as it seems to me we won't
really need many different terms, right?

On Thu, Jun 11, 2015 at 2:06 PM, Alasdair Gray [email protected]
wrote:

That ontology does not seem to have the types of property that we are
looking for, e.g. time that a sensor made a reading or time that the data
arrived at the processing engine.

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

from rsp-ql.

I think we will have to. Hence this issue to keep track of needing to do that.

from rsp-ql.

As far as I remember, some time ago we tried to use the Prov Ontology to represent sources and time of generation and consumption of streaming events by activities (things like generatedAtTime). Wonder whether some concepts could be used from there, along with a subset of concepts from the TIME ontology in OWL, instead of creating our own (even if small) vocabulary…

from rsp-ql.

ok, yes. why not! i'd agree. I just wasn't aware of the fact that we could
use a combination of ProvO and the TIME Ontology and that this might allow
us to model everything we need. I think we should put this on the Agenda of
our next call.

On Thu, Jun 11, 2015 at 2:30 PM, Alessandra Mileo [email protected]
wrote:

As far as I remember, some time ago we tried to use the Prov Ontology to
represent sources and time of generation and consumption of streaming
events by activities (things like generatedAtTime). Wonder whether some
concepts could be used from there, along with a subset of concepts from the
TIME ontology in OWL, instead of creating our own (even if small)
vocabulary…

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

from rsp-ql.

It is clearly a good idea to avoid having different terms for the same thing, but it would also be nice to allow other predicates if a relationship is desired that is not one of the standard terms.

from rsp-ql.

Dear all,
Sorry to enter a bit late into the discussion. Following the documents and emails I've seen that a timestamped graph is defined as a triple (g,p,t) where t is a time instant. The set of time instants is assumed (total) ordered and countable (isomorphic with N). As such I wonder which kind of predicates p are useful. I see "before" (g is available before time t), "after" (g is available after time t) and "at" (g is available at time t). Would be possible to have more like this?

from rsp-ql.

I would be wary of creating a new vocabulary for temporal properties (time points) unless there is a really strong use case which goes beyond, "before", "after", "at" and "until". I see these relationships appearing every now and again, especially in upper level ontologies and those that cover the events domain.

from rsp-ql.

The vocabulary in question here is not for time points or relationships between time points. It is for relationships between when a graph of triples was created/processed/received and the point in time that event occurred. For example
:g_1, prov:wasGeneratedAt, "2015-06-16T14:27:59+01:00"^^xsd:dateTime.

from rsp-ql.

prov:wasGeneratedAt looks to be quite similar with ex:at...A set of examples would be useful.similar question by https://github.com/keski at #11 He uses "observed at". But it looks that all "prov:generatedAt", ex:at and "observedAt" are quite similar.

from rsp-ql.

Ah yes indeed! I misinterpreted it. I remember I was looking for something similar when I wanted to associate my supply chain event graph with a timestamp. What is the interpretation of these operations? If the creating/processing/receiving of a graph is considered an event, one could use the upper level http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#hasEventDate property or at least specialise from it.

from rsp-ql.

yes, we thought about using the prov ones in one of the early discussions. @greenTara: sure I think we can define or provide some 'default' or 'recommended' time predicates, but the fact that we have 'p' in the model allows for defining 'custom' time predicates.

from rsp-ql.

@nimonika I would suspect that we would want to specialise so that we can accurately model the relationship.

from rsp-ql.

@AlasdairGray +1. I do it already :)

from rsp-ql.

There appear to be (at least) two dimensions that have to be captured in this predicate:

1. the type of event that is being described (e.g. observation, transmission)
2. the relationship between the time instant and the time interval of the event occurrence.
   Note that all real events take place on time intervals, so we have no choice about addressing time intervals at the conceptual level. That doesn't hinder us from using a time instant for the timestamp - we simply have to be specific about what the predicate tells us concerning the relationship between the time instant and the time interval in which the event happens.

from rsp-ql.

As I understood, the timestamp of the graph is provided by the listener, the RSP engine. Am I right?

from rsp-ql.

@greenTara Indeed. We need to allow for both time instants and time intervals. FWIW, if anyone needs to associate an occurrence of something with an interval, http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#isObservableAt can be exploited. The informal intuition may seem to be a time instant, but the range of this relationship is a http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#TimeInterval

from rsp-ql.

@agiurca This might not always be the case, especially if you have two timestamps associated with a graph. There could be an occurrence timestamp and a recorded timestamp. It depends which one(s) is/are importnat to be included in the serialised graph.

from rsp-ql.

@nimonika So, the RSP engine would assign an occurence timestamp (the event occurence) and a recorded timestamp (the time of serialization) ?

@greenTara The actual state of the art considers only time instants. If intervals would be considered then this should be updated in the wiki.

from rsp-ql.

@agiurca The occurrence timestamp would usually be assigned by a sensor for e.g., if it was capturing the occurremce of the event. The RSP engine would assign the recorded timestamp.

from rsp-ql.

@nimonika Should I understand that the RSP engine receives a graph which is already timestamped? I am not sure about that as that timestamp would be really complex...

from rsp-ql.

@agiurca "Should I understand that the RSP engine receives a graph which is already timestamped?" => yes. at least that's also how I see it. why should this timestamp be really complex?

from rsp-ql.

@agiurca No, the RSP engines receive the raw data through the sensors about the time of occurrence of the event.

from rsp-ql.

I see now. Thanks.

from rsp-ql.

@ agiurca Re: The actual state of the art considers only time instants. If intervals would be considered then this should be updated in the wiki.
At this stage, the time t of a time-stamped graph (g, p, t) is only allowed to be a time instant. However, it has been discussed on the mailing list (https://lists.w3.org/Archives/Public/public-rsp/2015Jun/0013.html) how it would be possible to use the predicate to emulate a time interval while still requiring t to be a time instant. For example, the duration of the interval would be coded into the predicate name, and the time-stamp would correspond to the start time of the interval.

from rsp-ql.

I dont know what to think of "the duration of the interval would be coded into the predicate name". So you mean that a predicate indicating a time interval duration of - let's say - 1h would look like lasts1h, resulting in a statement like <:graph1, :lasts1h, 2015-06-15T12:00:00>.

Is this what you propose? If yes, I think it's not a good idea to hardcode the duration into the predicate name. If I miss something obvious, I am sorry though.

I think when @AlasdairGray was talking about the possibilty of modeling intervals with the <g,p,t> approach, he was thinking about something like:
<:graph1, :startsAt, 2015-06-15T12:00:00>
<:graph1, :endsAt, 2015-06-15T13:00:00>

Please correct me, if I'm wrong. Moreover, I'd be interested in what would be the preferred approach to model intervals for us?

from rsp-ql.

@beta2k Yes, it is a good idea to spell out the specifics so we know exactly what the proposals mean. I was think in terms of encoding the duration in the predicate name, but I was think of something more REST-y, such as (namespace)/startsAt?duration=PT1H, where the value is an xsd:duration. If the duration is missing, it reverts to (namespace)/startsAt with unspecified duration.

As to
<:graph1, :startsAt, 2015-06-15T12:00:00>
<:graph1, :endsAt, 2015-06-15T13:00:00>
This involves giving an explicit name to the graph so that it can be used more than once, without repeating the graph in the transmission. If that is an option, then I agree that this is possible, but it is more verbose than adding a query string to the predicate. Also the definition of time-stamped graph does not cover this case as written, because it just defines a structure of three elements where the first is the graph itself, not the name of a named graph.

from rsp-ql.

Yes, for the :startsAt and :startsEnd example, we would need to give the graph a name. And I agree, that it's a bit verbose. In my opinion however, the current definition of a timestamped graph does not necessarily disallow using the name of a named graph instead of using just the graph itself. At least, I dont see that in <g,p,t> the g cannot be the name of a named graph? Then again, I am not too sure.

I'd like @AlasdairGray's and @jpcik's take on this:
a) does <g,p,t> allow g to be the name of a named graph, or is it restricted to being only the graph itself?
b) I am not sure about encoding the duration in the predicate name. Since we talk about RDF statements/triples, I have never seen information encoded in a predicate's name in a REST-y style as you have shown above, i.e., (namespace)#startsAt?duration=PT1H. Is this common practice? I've never seen it.

from rsp-ql.

Note: I edited my post above to chang the REST-y predicate to have a slash separator because in the IRI specification, the query string must come before the fragment identifier. I don't know if it is common practice to include query strings in RDF predicates, but it is technically valid based on https://www.ietf.org/rfc/rfc3987.txt.

from rsp-ql.

a) does <g,p,t> allow g to be the name of a named graph, or is it restricted to being only the graph itself?

As you say, we have not precluded g being used as the URI for the timestamped graph and this is consistent with the RDF Dataset Semantics suggested.

Personally I would be in favour of using URIs rather than blanksnames so that you can reference them later on.

I think when @AlasdairGray was talking about the possibilty of modeling intervals with the <g,p,t> approach, he was thinking about something like:
<:graph1, :startsAt, 2015-06-15T12:00:00>
<:graph1, :endsAt, 2015-06-15T13:00:00>

This is exactly what I had in mind. I had not really been thinking about the predicate or the time parameter providing the duration.

I dont know what to think of "the duration of the interval would be coded into the predicate name". So you mean that a predicate indicating a time interval duration of - let's say - 1h would look like lasts1h, resulting in a statement like <:graph1, :lasts1h, 2015-06-15T12:00:00>.

b) I am not sure about encoding the duration in the predicate name. Since we talk about RDF statements/triples, I have never seen information encoded in a predicate's name in a REST-y style as you have shown above, i.e., (namespace)#startsAt?duration=PT1H. Is this common practice? I've never seen it.

I would be completely against this approach as it hides the semantics in an non-machine readable form which is just as bad as not having it at all.

Given the use cases that are coming forward, should we be considering predicates of the form

:g_1 :validForDuration "PT1h"^^xsd:duration .

:g_2 :validBetween 
    [:startsAt "2015-06-18T09:30:23+01:00"^^xsd:dateTime; 
    :endsAt "2015-06-18T10:30:23+01:00"^^xsd:dateTime]

from rsp-ql.

Personally I would be in favour of using URIs rather than blanksnames so that you can reference them later on.

I agree.

I would be completely against this approach as it hides the semantics in an non-machine readable form which is just as bad as not having it at all.

I agree again. This is what made me worried about this approach.

Given the use cases that are coming forward, should we be considering predicates of the form

:g_1 :validForDuration "PT1h"^^xsd:duration .

:g_2 :validBetween 
    [:startsAt "2015-06-18T09:30:23+01:00"^^xsd:dateTime; 
    :endsAt "2015-06-18T10:30:23+01:00"^^xsd:dateTime]

Is this is a question to decide between the two appraoches or just an example of how it could be done?

from rsp-ql.

Given the use cases that are coming forward, should we be considering predicates of the form
:g_1 :validForDuration "PT1h"^^xsd:duration .
:g_2 :validBetween [:startsAt "2015-06-18T09:30:23+01:00"^^xsd:dateTime; :endsAt "2015-06-18T10:30:23+01:00"^^xsd:dateTime]
Is this is a question to decide between the two appraoches or just an example of how it could be done?

Both of these are not currently covered by the proposed model since it says that the third component is a time instant and neither of the objects of these triples are time instants.

So it is a proposal to extend the data model.

from rsp-ql.

:g_1 :validForDuration "PT1h"^^xsd:duration

Imho, here we still need a statement stating what is the start/middle/end of this duration. So we'd still need a separate statement like :g_1 :startsAt "2015-06-18T10:30:23+01:00"^^xsd:dateTime.

Imho we would then end up with something similar as stated already above, that is:

:g_1, :startsAt, "2015-06-18T12:00:00"^^xsd:dateTime
:g_1, :endsAt, "2015-06-18T13:00:00"^^xsd:dateTime

The difference is only that in one appraoch we use 1 xsd:dateTime + 1 xsd:duration and in the other approach we use 2 xsd:dateTimes.

All in all, this leads me to be in favor of

:g_2 :validBetween
    [:startsAt "2015-06-18T12:00:00"^^xsd:dateTime;
    :endsAt "2015-06-18T13:00:00"^^xsd:dateTime]

Obviously, this adds a blank node, but - in that case - it doesn't hurt much. Generally, it would be nice, if our model would not be that restrictive. So it should allow either cases. That would allow eventual 'users' to choose one of the approaches. Is that doable?

Opinions of others would be interesting :)

from rsp-ql.

or if you want to go beyond xsd:datetime, you can use an interval, using ISO 8601 (the same we use for window durations). I think you just separate start and end times with a "/",
In any case I think we can say that the model allows representing all these fancy things (And show examples), but for the current query language we limit to timepoints.

from rsp-ql.

how about using intervals (with start and end) from Dolce Ultralight (DUL) as done in other models e.g. here: Event Model F

from rsp-ql.

@stuehmer: Using DUL vocab for modelling intervals was already proposed above by @nimonika. We should definitely consider it.

@jpcik : Yes, generally I'm also in favor of the KISS principle, that is in this case, limiting the query language to timepoints, but list all these other possibilities of representations in our report.

We just need to make sure, imho, that our model is open enough (in other words: not too restrictive) in order to allow these other fancy representations syntactically.

from rsp-ql.

In extending from time instants to more general kinds of temporal entities, the notion of ordering by timestamp becomes unclear. It was my understanding that this was the reason to restrict to time instants at this point.

from rsp-ql.

Re: "As you say, we have not precluded g being used as the URI for the timestamped graph and this is consistent with the RDF Dataset Semantics suggested."
This may be the intention, but it was not what the document at https://github.com/streamreasoning/RSP-QL/blob/master/Semantics.md says. It says g is an RDF graph. This wording, as a normative definition, does not leave any room for an interpretation that "g" is an IRI or blank node that is the name of a named graph.

Rather than try to reword the definition of time-stamped graph, I think it is time to start from scratch with a list of characteristics, mandatory and optional, of a time-stamped graph. Once that is agreed upon, then a definition can be drafted that rigorously achieves those characteristics.

However, the issue here is focused only on the terms to be used for the predicate. I am opening a new issue regarding the definition of time-stamped graph. #13

from rsp-ql.

Please also consider sources such as http://www.omg.org/spec/DTV/1.1/PDF/
In this approach "timepoints" are always time intervals, and any given time scale has a non-zero granularity - i.e. there are no time instants in this approach.

from rsp-ql.

It is better to keep time instants in the tuple (g, p, t) as keeps the future standard simple. This is a core feature. Adding more complex time processing should be subject of developed use cases.

from rsp-ql.

I think duration only without event start/end timestamp might not be useful data for the use cases.

In most event processing use cases, events are processed based on their arriving - their stream sequence. However, in some cases it is useful to know the timestamp event generation to reorder the events if needed, or store their generation time for later processing.

I think the data model (g,p,t) where t is an "instance of time" would be fine, but not adding the model (g,p,d) where d is the "duration or validation of the graph".

One might define a quad data model (g, p, t, d) where d is optional. :)

from rsp-ql.

It is better to keep time instants in the tuple (g, p, t) as keeps the future standard simple. This is a core feature. Adding more complex time processing should be subject of developed use cases.

+1

from rsp-ql.

initial version added by 224f660

from rsp-ql.

updated by a913be7

from rsp-ql.

On the last telco, we discussed about a couples of issues related to the Time vocabulary that I will try to describe here:

1. receivedAtTime and transmittedAtTime properties define a relation between a graph and a timestamp. What happens when an RSP engine receives a timestamped graph including these two properties and transmits the graph again? Should the RSP engine overwrite these properties? In the case that the last RSP engine does not overwrite the properties and add new receivedAtTime and transmittedAtTime timestamps, how do we keep track of which RSP engines are receiving and transmitting the graph?
2. To justify that a property in the Time vocabulary is needed, we should relate the properties at the vocabulary with the use cases we have at the wiki, or add new (real) use cases that justify such properties.

from rsp-ql.