Re: AW: [RSP] Call Minutes

+1 for Darko proposal!

I would only add that other timestamps may be needed to represent other information, e.g. receivedAt, the time at which a streamed graph gets to the RSP. For a given graph this timestamp always follows the timestamp at which a simple event is observed. We may want to provide a minimal (and extendable) ontology for those timestamps.

Cheers,

Emanuele 

Inviato da iPhone

Il giorno 13/dic/2013, alle ore 17:13, "Anicic, Darko" <darko.anicic@siemens.com> ha scritto:

> Axel,
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Axel Polleres [mailto:droxel@gmail.com] Im Auftrag von Axel Polleres
>> Gesendet: Donnerstag, 12. Dezember 2013 18:04
>> An: Anicic, Darko
>> Cc: Emanuele Della Valle; Jean-Paul; public-rsp@w3.org
>> Betreff: Re: [RSP] Call Minutes
>> 
>> Darko,
>> 
>> you are bringing validity time into the picture, it seems. whereas I
>> understood that the use for time stamps at the moment was mainly meant for
>> transaction time. [1] is that right? If we have use cases that need
>> validity time, I also think intervals make sense (FWIW, we have designed an
>> extension for SPARQL to query validity time intervals [2]).
> 
> Yes, for validity time of facts, but also for defining the time on which complex events have been derived. As stated in [1]: "Simple events happen at a single time instant, complex events start and end happening whereas facts always have a time interval during which they are valid.". Hence simple events could be represented as a graph with a single timestamp, complex events and facts could be represented as graphs defined on intervals. The meaning of the intervals for complex events and facts have different interpretations (and need semantics to be defined), i.e., complex events have been derived (occurred in the past) in an interval, whereas facts are valid in an interval (an interval possibly extended until certain point in the future).     
> 
> Essentially if we have the interval-based graphs (e.g., with startTime and endTime where the startTime is optional), then we can represent the all three categories with no overhead.
> 
> Cheers,
> Darko
> 
> [1] http://www.w3.org/community/rsp/wiki/RDF_Stream_Models#Temporal_Graphs 
> 
>> 
>> best,
>> Axel
>> 
>> 1. http://en.wikipedia.org/wiki/Temporal_database
>> 2. http://www.sciencedirect.com/science/article/pii/S1570826811000771
>> 
>> --
>> Prof. Dr. Axel Polleres
>> Institute for Information Business, WU Vienna
>> url: http://www.polleres.net/  twitter: @AxelPolleres
>> 
>> On Dec 12, 2013, at 5:05 PM, "Anicic, Darko" <darko.anicic@siemens.com>
>> wrote:
>> 
>>> Hi Jean-Paul, Emanuele and all,
>>> 
>>> I like the proposal too, but I would not limit the proposal only to one
>> time stamp. As we discussed before, I find the interval-based definition
>> better, e.g., with startTime and endTime. The startTime may be optional in
>> cases where the point-based timestamp is preferred, e.g., similarly as in
>> [1] - a related approach to the Streaming Linked Data Framework, sent by
>> Emanuele (see #6 in Section Vocabulary from [1]).
>>> 
>>> Cheers,
>>> Darko
>>> 
>>> [1]   http://km.aifb.kit.edu/sites/lodstream/
>>> 
>>> Von: Emanuele Della Valle [mailto:emanuele.dellavalle@polimi.it]
>>> Gesendet: Dienstag, 10. Dezember 2013 11:15
>>> An: Jean-Paul; Anicic, Darko; public-rsp@w3.org
>>> Betreff: Re: [RSP] Call Minutes
>>> 
>>> Hi Jean-Paul, Darko and all,
>>> 
>>> I like the proposal. You may want to check out [1] where a similar
>> approach was proposed. We named the graphs o *instantaneous graphs*
>> (shortly iGraphs) and the graph containing the meta data Stream Graph
>> (shortly sGraph). This solution is currently implemented in our Streaming
>> Linked Data Framework [2].
>>> 
>>> GRAPH :sGraphA {
>>>  :iGraph-1 :timeStamp "t_1"^^xsd:dateTimestamp .
>>>  :iGraph-2 :timeStamp "t_2"^^xsd:dateTimestamp .
>>>  .
>>>  :iGraph-n :timeStamp "t_n"^^xsd:dateTimestamp .
>>> }
>>> 
>>> GRAPH :iGraph-1 {.}
>>> GRAPH :iGraph-2 {.}
>>> 
>>> GRAPH :iGraph-n {.}
>>> 
>>> Cheers,
>>> 
>>> Emanuele
>>> 
>>> [1] http://ceur-ws.org/Vol-628/ldow2010_paper11.pdf
>>> [2] http://disi.unitn.it/~themis/publications/iswc13.pdf
>>> 
>>> 
>>> 
>>> On Dec 9, 2013, at 5:07 PM, Jean-Paul
>>> <jpcalbimonte@delicias.dia.fi.upm.es>
>>> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> The one in [1] is a very generic model proposed by Axel. We agreed to
>> start from it to define the RDF Stream model.
>>> If you see the minutes, you will see we are pointing to something that
>> *might* look like this:
>>> 
>>> o :timeStamp "foo"^^xsd:dateTimestamp . GRAPH o { t1, tn}
>>> 
>>> We have set an ACTION, that consists in formalizing these ideas in the
>> wiki. It is our homework for next call. But we can surely discuss here as
>> well.
>>> 
>>> best regards,
>>> jp
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2013/12/9 Anicic, Darko <darko.anicic@siemens.com> Hi all,
>>> 
>>> since I was not present at the last telco, could you please let me know
>> whether the RDF stream model that was discussed actually is the one
>> described as "graph oriented" in [1], or there are some differences in the
>> two?
>>> Cheers,
>>> Darko
>>> 
>>> [1] http://www.w3.org/community/rsp/wiki/RDF_Stream_Models
>>> 
>>> Von: jean.paul.ik@gmail.com [mailto:jean.paul.ik@gmail.com] Im Auftrag
>>> vonJean-Paul
>>> Gesendet: Samstag, 7. Dezember 2013 00:19
>>> An: public-rsp@w3.org
>>> Betreff: [RSP] Call Minutes
>>> 
>>> Hi all,
>>> 
>>> Please find in the wiki the minutes of today's call. Next one is on Dec
>> 20th, and is the last for 2013. We will restart in January, the 17th.
>>> 
>>> http://www.w3.org/community/rsp/wiki/Telecon_06.12.2013
>>> 
>>> Thanks again for your support.
>>> 
>>> Good weekend!
>>> Jean-Paul
>>> 
>>> --
>>> jpcik!
>>> 
>>> 
>>> 
>>> ---------------------------------
>>> I have moved to EPFL, please email me to:
>>> jean-paul.calbimonte@epfl.ch
>>> 
>>> 
>>> 
>>> --
>>> jpcik!
>

Received on Friday, 13 December 2013 16:41:51 UTC