Telecon 06.12.2013

From RDF Stream Processing Community Group

Participants

  • Alasdair Gray
  • Jean-Paul Calbimonte
  • Oscar Corcho
  • Chan Le Van
  • Daniele Dell'Aglio
  • Josiane X. Parreira
  • Mikko Rinne
  • Manfred Hauswirth
  • Axel Polleres

Apologies:

  • Emanuele Della Valle
  • Darko Anicic

Agenda

  • A Common RDF Stream model
    • Time-based order in data
    • Flexibility in granularity of timestamps
    • Compatibility with standard RDF
    • Timestamps for graphs
  • Limitations of existing models
  • Next calls


Minutes

A common RDF Stream Model

Order and timestamps

  • Oscar Corcho: Goal: Discuss on a common RDF Stream model
  • Jean Paul: from last meeting, we agreed that elements in a stream should have some order related to time.
  • Axel Polleres: RDF streams ordered in terms of time… Are they?
  • Manfred: We must be aware there are different use cases where stream elements may arrive out of order and clocks are not necessarily in sync
  • Manfred: in the distributed case, timestamps differ, and stream data is out of order
  • Manfred: In a fully distributed environment this is usually the case, we have to show that we are aware of this even if at first we narrow the problem
  • Jean Paul: now we have to discuss on how this time notion needs to be expressed
  • Axel Polleres: events with different timestamps may come in in different order from different sources
  • Axel Polleres: (guess that's where manfred is getting at)
  • Manfred: in principle, the stream needs to be ordered. Ok, we ...
  • Oscar Corcho: ACTION: make sure that we express this very explicitly upfront, so as to avoid confusion later when somebody reads what we are writing about.

Modelling: timestamped triples, and graphs

  • Axel Polleres: that's also touching on the model I tried to suggest here, which should cover what is now being deiscussed, BTW… [1]
  • Axel Polleres: does it make sense what I am saying?
  • Axel: according to the comment on the previous URL/message, both aspects may need to be considered.
  • Josi: should both of them handled in the modelling or is it really that there is no difference only when we are talking about the processing
  • Daniele: probably this is something that can be better addressed if we talk about timestamping graphs and not triples
  • Oscar: we should make some assumptions and be more operational, and then (in 1/2 months) we can move to another case
  • Oscar: given that we have several possible scenarios and we are not completely sure that we could just get a common model for all of them (although maybe we can, as per Axel's comment), it may be good to work first on a very specific case with a very clear set of assumptions, and then do the whole process (define semantics of the model, evaluation, etc.)
  • Oscar: then we can move forward trying to generalise the model with other scenarios.
  • Axel Polleres: I think (as written in [2]) that the most generic model is "streams of timestamped streams of triples", and all other models are special cases for this model.
  • Axel Polleres: which is equivalent in some sense to "streams of timestamped triples" (that may appear out of timestamp order)
  • Oscar: general question: are we all happy to try to start from the initial description from Axel (as per the URL above) and start working on the documents offline for the next weeks?
  • Jean Paul: it seems to cover most cases that we were considering. The main difference wrt previous works seems to be considering more than one triple per timestamp
  • Alasdair: The key aspect to be captured by the model is that a set of triples bring in some "object" together
  • Josi: isn't it the same thing to allow any set of triples with the same timestamp?
  • Josi: basic agreement seems to be that the model should allow different triples to have the same timestamp
  • Alasdair: be aware that triples with the same timestamp are not necessarily about the same event
  • Axel Polleres: yes, I agree with the graph per timestamp model being somewhat equivalent… why I brought in RDF streams per timestamp as opposed to graphs per timestamp was because I didn't want to make a committment on whether you'd know when the information of one timestamp (from one source) is complete.
  • Axel Polleres: imagine that you want to transmit an object as triples, you want means to "keep the object together"
  • Axel Polleres: graphs are fair enough.
  • Axel Polleres: o :timeStamp "foo"^^xsd:dateTimestamp . GRAPH o { t1, … tn}
  • Oscar Corcho: ACTION (all): write down this notion that we have been discussing (and almost agreeing)
  • Oscar Corcho: ACTION (Jean Paul): organise the writing of this notion, with a couple of volunteers

RDF compatibility

  • Jean-Paul: Next thing to consider: compatibility with the RDF model
  • Alasdair: it seems that adding a timestamp to graphs is not really difficult to be encoded even syntactically in current RDF
  • Oscar Corcho: ACTION (all): check whether there is any case where there would not be any compatibility with the current RDF model
  • Oscar Corcho: Agreement on working on this on a wiki basis, but letting others know when some relevant edits have been done, to allow others in the mailing list to discuss

Misc

  • Jean-Paul: Agenda item: when to do next calls
  • Oscar Corcho: Dec 20th, Jan 17th, and so on biweekly
  • Axel Polleres: sounds good.

Actions

  • ACTION (all): write down this notion that we have been discussing (and almost agreeing) (RDf stream model)
  • ACTION (Jean Paul): organise the writing of this notion, with a couple of volunteers (RDF stream model)
  • ACTION (all): check whether there is any case where there would not be any compatibility with the current RDF model
Retrieved from "https://www.w3.org/community/rsp/wiki/index.php?title=Telecon_06.12.2013&oldid=119"