- From: Tara Athan <taraathan@gmail.com>
- Date: Fri, 25 Sep 2015 12:02:01 -0400
- To: public-rsp@w3.org
I have revised the discussion points from an earlier email based on todays' telecon: * The requirement in the definition of “substream” that it be finite is not consistent with the conventional use of the “sub” prefix in mathematics. It was proposed in the telecon that the finiteness requirement be removed from the definition. It is still ok to have "substream" and "window" be synonyms - as mentioned, other approaches have windows that are unbounded. "Substream"/"window" should be considered a property, in the sense of rdf:Property, whereas "stream" is an rdfs:Class. - The new class of "finite stream" could be defined, as a subclass of "stream", to formalize the finiteness property. Example 1: if a stream S is filtered to remove all timestamped graphs except those with a certain predicate `p`, then we obtain S' which is a substream of S. Example 2: If two streams S1 and S2 are merged, then each of the original streams are substreams of the merged stream S3. * Regarding ordering of timestamps, I propose we consider the partial order over time instants and time intervals defined as follows: 1. time instants are treated as equivalent, for the purposes of this comparison, to a degenerate time interval where the start and end times are the same 2. time intervals are treated as closed for purposes of this comparison 3. If two timestamps have different end times, then the timestamp with the later end time is greater than the timestamp with the earlier end time (irregardless of the start time). 4. If two timestamps have the same end times, then the timestamp with the later start time is greater than the timestamp with the earlier start time. Note 1: if we define the `closure` of a temporal entity as the smallest closed time interval containing it, then the partial order above can be defined in terms of a total order on closed time intervals. Note 2: this is one possible partial ordering, which is appropriate for e.g. predicates related to aggregate properties (e.g. the average of something over the period of observation) which should not be transmitted until the observation is finished. Other partial orderings, e.g. an ordering based solely on start time, ignoring end time altogether, could be used for a different kind of timestamped graph, provided it is associated with some timestamp predicate. * In regard to the concern about multiple triples needed to express metadata of a graph - we need an example. But in general, RDF metadata, however complex it is, is just another graph, so such metadata could be represented as another time-stamped graph in the stream, e.g. with the same timestamp but different predicate expressing the relation “describes an observation that was observed at". This metadata graph would refer to the other timestamped graph by name (which therefore could not be a blank node). Possible disadvantage - as currently defined, a simple count-based window function could capture an observation but not its metadata, or vice versa. However, more complex window functions could be defined that don't have this problem. As an alternative, we could consider allowing a timestamped graph to contain multiple ```named``` graphs, as follows: default graph: (n_1, p_1, t_1) first named graph: (n_1, g_1) second named graph: (n_2, g_2) where g_1 can refer to n_2 e.g. g_1 = { (n_2, p_2, t_2), (n_2, q_1, d_1), ...} is the metadata of g_2 Best regards, Tara
Received on Friday, 25 September 2015 16:02:29 UTC