Re: optimizing container pages serialization to enable streaming

* Alexandre Bertails <bertails@w3.org> [2013-11-11 13:18-0500]
> On 11/11/2013 12:48 PM, Eric Prud'hommeaux wrote:
> >During the call, I asserted that seeing
> >   <ContainerX> ldp:membershipRule [];
> >with default properties assumed for the blank node doesn't prevent
> >future non-monotonic assertions (e.g.
> >   Class: <ContainerX>
> >       SubClassOf: (
> >           ldp:membershipRule some (
> >               ldp:insertedContentRelation some foo:bar))
> >). While strictly true, the issue here is not monotonicity but
> >pragmatic ordered serialization to enable a client to interpret
> >the data as it arrives. Let's call that "streaming".
> 
> Why am I thinking that specifying an order on the streamed RDF triples
> does not feel like RDF anymore?

Well, it certainly is outside of pure RDF, but to be pragmatic, there
is no RDF solution. (XML had this prob with regard to a long document
being invalid at the end after side effects in some SAX tool.) There
is an HTTP solution, i.e. shove more stuff into headers, but that just
hides useful info from RDF. In the end, I think there's nothing better
than hinting that folks who care about performance write some tweaks
into their serializers.


> Are we specifying a state machine?

That'd be a crazy spec to read.


> Alexandre.
> 
> >
> >To Henry's point, we could enable streaming and enable defaults by
> >adding a ldp:membershipRule along with a change to 5.3.1 (and tweaks
> >to the pending mods to Membership triples):
> >  s[[
> >5.3.1 The representation of a LDPC MUST contain a set of membership
> >triples following one of the consistent patterns from that
> >definition. The membership-constant-URI of the triples MAY be the
> >container itself or MAY be another resource (as in the example).  See
> >also 5.2.3.
> >]][[
> >5.3.1 The representation of a LDPC MUST contain exactly one
> >ldp:membershipRules statement with the subject of the
> >membership-constant-URI and an object a blank node. All membership
> >triples use this blank node as the subject. The
> >membership-constant-URI of the triples MAY be the container itself or
> >MAY be another resource (as in the example).  See also 5.2.3.
> >]]
> >
> >Observant readers of the spec will probably notice that it'd be wise
> >to serialize this at the beginning of the page, but we can point that
> >out in informative text under 5.3.1, in the primer, or both.
> >
> >The downside is that membership triples really aren't about the blank
> >node but instead about the membership-constant-URI which has a
> >ldp:membershipRule relationship to the blank node. Also, bnodes freak
> >some people out, but that's probably pretty managable.
> >
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Monday, 11 November 2013 18:36:30 UTC