- 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