RDF Stream Profile: Linked List

greenTara commented 8 years ago

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

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

greenTara commented 8 years ago

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

kiat commented 8 years ago

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

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

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

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

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

Do we have any proposals for the timestamp predicate?

greenTara commented 8 years ago

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

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

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

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

danhlephuoc commented 8 years ago

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

@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.

streamreasoning / RSP-QL

RDF Stream Profile: Linked List #56