RDF Stream Profile: Linked List

[greenTara]

There is a form of RDF stream that does not give complete information about timestamps, but only provides order information. A useful form is a linked list, e.g.

:g1 :p _:t1.
:g1 {...}.

:g2 :p _:t2.
_:t2 time:after _:t1
:g2 {...}.

... 

where _:t1 and _:t2 are OWL-TIME temporal entities.

It would be helpful to have a concrete usecase for this profile, as well as a specification. The temporal information provided in such an RDF stream should be sufficient for detection of complex events where the pattern is based on the order of its sub-events.

[beortner]

For the sensor domain an use case may be sensor configurations, calibrations or error detection.

[greenTara]

@beortner If you could provide a concrete example, it would be really helpful.

[kiat]

We can use the same simple example that we have already in the document.
like this:

---

:g1 :p _:t1.
:g1 {:axel :enter :RedRoom. :darko :enter :RedRoom }

:g2 :p _:t2.
:g2 {:axel :leave :BlueRoom. }
_:t2 time:after _:t1

:g3 :p _:t3.
:g3 {:tara :enter :RedRoom. :darko :leave :RedRoom }
_:t3 time:after _:t2

:g4 :p _:t4.
:g4 {:axel :enter :RedRoom. }
_:t4 time:after _:t3

---

Simple queries are like

• Which persons meet in red room?

I think using this example we could keep it simple and understandable.

One important point is that the RSP system should be able to reason over the blank node times.

@greenTara: Or do you want to have some real examples from event processing use cases?

[greenTara]

This example is good for the document, because it is similar to the other examples, so it is easy to see what the differences are. One point I think we should change (in all the examples) in order to make things clear - we should use a real timestamp predicate, not just :p .

For the use case wiki page https://www.w3.org/community/rsp/wiki/Use_cases, it would be best to describe more realistic examples.

[kiat]

ok, time stamps like this
time:inXSDDateTime 2016-01-01T10:30:00-5:00 .

I will go over the use cases and try to find some good ones that can have such cases.

[greenTara]

We don't at present have a good timestamp predicate for this case:

• time:inXSDDateTime is not a timestamp predicate - the domain is time:Instant, not an RDF graph
• The predicate prov:generatedAtTime is not applicable to this case, because the range is xsd:dateTime, not time:TemporalEntity (or some other "entity" class).

I think we need to create new timestamp predicates, in some RSP namespace, specifically for this case. This is a long-standing issue #10 .

[kiat]

Yes, I see the domain is not an RDF graph.

Do we have any proposals for the timestamp predicate?

[greenTara]

Here is a possibility: from https://www.w3.org/2005/Incubator/ssn/ssnx/ssn

http://purl.oclc.org/NET/ssnx/ssn#observationSamplingTime

It is a subproperty of http://www.loa-cnr.it/ontologies/DUL.owl#hsRegion, which doesn't appear to have any restriction of the domain, and the range is http://www.loa-cnr.it/ontologies/DUL.owl#Region, which has subclass http://www.loa-cnr.it/ontologies/DUL.owl#TimeInterval.

Although it doesn't appear in the formal ontology, the SSN specification indicates that the domain of ssn:observationSamplingTime is intended to be ssn:Observation, which is a subclass of DUL:Situation.

I don't know how much as stretch it would be to say that a graph name denotes a DUL:Situation. It is not that far off from the semantics motivation, which is "every graph defines its own context".

Note thate Dolce has its own predicate http://www.loa-cnr.it/ontologies/DUL.owl#isObservableAt, which has arbitrary domain and range of DUL#TimeInterval. We would have more freedom in using this compared to the more constrained ssn predicate.

[beortner]

@kiat Regarding realistic use cases:
lat / long from movement paths of sensors are usually modelled as Linked list, .e.g
https://www.w3.org/community/rsp/wiki/Use_cases#Urban_Transport_Assistance

Sample Query:

• get areas with increased gps activity within a certain timespan ( 1 day / hour)

Furthermore I found another Use Case :
some states / events are also modelled as linked list, e.g.
https://www.w3.org/community/rsp/wiki/Use_cases#Monitoring_of_Multi-Cloud_Applications

[lisp]

... because the range is xsd:dateTime, not time:TemporalEntity.

why is that a requirement for the "linked list" use cases?

[danhlephuoc]

Regarding to temporal predicates for stream data, there is on-going work of Spatial on The Web working group(https://www.w3.org/2015/spatial/) that is discussing about OWL-Time and SSN(especially, temporal aspects of sensor observations), there a big list of relevant use cases at https://www.w3.org/2015/spatial/wiki/Working_Use_Cases, for example, I found this UC proposed by a fellow from Bosch quite interesting for temporal predicates, https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Driving_to_work_in_the_snow_.28SSN.2C_Time.2C_Coverage.29

[greenTara]

@lisp - In principle, a predicate with range xsd:dateTime could be used for a linked list, with an IRI or blank node indicating the timestamp, but I think this would be confusing to readers, and it would limit the entailment regimes applicable to that stream, as the stream would be inconsistent in the OWL-DL entailment regime.[1]
The timestamp of a linked list does not have to be a time:TemporalEntity (I have edited the earlier comment). However time:TemporalEntity is the domain and range of time:after, which is used in the example for expressing the "links" of the linked list.

[1] While it is true that in the simple entailment regime, the value space of a datatype is a subclass of rdf:Resource, and so could be represented by an IRI or blank node, that is not permissible in OWL-DL.