Re: [rsp] Streaming with TriG?

+1

On 21/03/14 13:47, Daniele Dell'Aglio wrote:
> Hi all,
> I also like the proposal, but I think that first we should define the
> data model, and only after that we should discuss about its
> serialization (and here, Trig can be a solution).
> Just to make some examples:
> - we didn't reach a consensus about how put the timestamps (and how many
> timestamps)
> - can a stream bring the same graph different times (maybe with
> different triples)? I mean, what happens if the the stream contains:
> GRAPH :g1{...}  [after some time/elements] GRAPH :g1{...}
> - who decide the timestamp(s) associated to a graph? Let's for example
> consider a case with one timestamp representing the validity of the
> graph. What happens if two streams describes the same graph with
> different timestamp values?
>
> So, I really think that we need to understand what is a stream of
> graphs, and only after we can discuss about the syntax and how to
> implement it.
>
> Daniele
>
> On 03/21/2014 02:21 PM, Roland Stühmer wrote:
>> 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
>>
>
>

-- 
Prof. Manfred Hauswirth
INSIGHT Centre for Data Analytics
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway
http://www.manfredhauswirth.org/

Received on Friday, 21 March 2014 14:17:34 UTC