- 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