- From: Roland Stühmer <mail@roland-stuehmer.de>
- Date: Fri, 21 Mar 2014 14:21:58 +0100
- To: Mikko Rinne <mikko.rinne@aalto.fi>, public-rsp@w3.org
Hi Mikko!
I like it. I am using Trig in my streaming system DCEP [1] inside SOAP
messages but also in plain HTTP streaming [3].
https://github.com/play-project/play-commons/tree/master/play-commons-eventformat
By the way an alternative way for a receiver to know when an event
(composed of many triples) is finished we can use HTTP chunked
connections [4]. The connection is long-lived (like a subscription) but
the sender sends a new HTTP chunk for every single event. Start and end
and the size of chunks can be detected by the receiever thanks to pure
HTTP 1.1.
Best!
Roland.
[1] https://github.com/play-project/play-dcep/
[3]
https://github.com/play-project/play-eventadapters/tree/master/play-eventadapter-ldstreams
[4] http://en.wikipedia.org/wiki/Chunked_transfer_encoding
On 21.03.2014 14:11, Mikko Rinne wrote:
>
> Hi, All!
>
> TriG (http://www.w3.org/TR/trig/) reached W3C recommendation status in
> February. As it has the basic support for streaming named graphs, there
> have been some discussions in our team on whether we should take it into
> use. As I haven't seen any discussion on the list or in the RSP CG
> minutes on TriG, I was wondering whether there are already strong views
> for or against?
>
> For those not familiar with TriG, it is " an extension of Turtle,
> extended to support representing a complete RDF Dataset". A couple of
> sample events could be represented in TriG like this:
>
> -------------TriG-------------
>
> *
>
> @prefix : <http:example.org/default#> .
>
> @prefix ep:
> <http://www.ontologydesignpatterns.org/cp/owl/eventprocessing.owl#> .
>
> @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
>
>
> :ev1 { [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.158776 ; geo:long 24.881490 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T09:18:21"^^xsd:dateTime . }
>
>
> :ev2 { [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.187458 ; geo:long 24.821272 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T09:42:00"^^xsd:dateTime . }
>
>
> :ev3 { [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.187634 ; geo:long 24.821491 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T10:18:21"^^xsd:dateTime . }
>
> *
> -------------------------------
>
> It is not terribly different from doing the same with SPARQL Update:
>
> -----------SPARQL Update-------------
>
> *
>
> PREFIX ep:
> <http://www.ontologydesignpatterns.org/cp/owl/eventprocessing.owl#> .
>
> PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
>
>
> INSERT DATA {
>
>
> GRAPH <http:example.org/default#ev1> {
>
> [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.158776 ; geo:long 24.881490 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T09:18:21"^^xsd:dateTime . }
>
>
> GRAPH <http:example.org/default#ev2> {
>
> [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.187458 ; geo:long 24.821272 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T09:42:00"^^xsd:dateTime . }
>
>
> GRAPH <http:example.org/default#ev3> {
>
> [] a ep:EventObject ;
>
> geo:Point [ geo:lat 60.187634 ; geo:long 24.821491 ; ] ;
>
> ep:hasEventObjectSamplingTime
> "2014-01-07T10:18:21"^^xsd:dateTime . }
>
>
> } # end-of INSERT DATA
>
> * -------------------------------
>
> The nice thing about TriG is that it would be easier to synchronize in
> the middle of a stream (no "INSERT DATA" needed).
>
> Encapsulating streaming objects into graphs has the benefit, as pointed
> out earlier by Axel, that the end of the object is explicitly marked.
>
> What do you think?
>
> Mikko
Received on Friday, 21 March 2014 13:22:22 UTC