Re: [rsp] Streaming with TriG?

+1

On 21.03.2014, at 15:12, Manfred Hauswirth <manfred.hauswirth@deri.org> wrote:

> +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/
> 

-----------------------------------------------------------------
|  Professor Abraham Bernstein, PhD
|  University of Zürich, Department of Informatics
|  web: http://www.ifi.uzh.ch/ddis/bernstein.html

Received on Sunday, 23 March 2014 11:49:01 UTC