Re: optimizing container pages serialization to enable streaming

* Alexandre Bertails <bertails@w3.org> [2013-11-11 13:44-0500]
> On 11/11/2013 01:35 PM, Eric Prud'hommeaux wrote:
> >* 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.
> 
> There is one: don't define defaults.

Writing explicitly required arcs at the bottom of a long document
doesn't address the streaming problem.


> >(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.
> 
> The header trick can only be used if you're not changing the
> fundamental nature of the media-type. We can always define a way for
> the server to tell the client that it has an RDF alternative of the
> content, and a paged version. Paging is not adding a new capability,
> it is changing the behavior the client.
> 
> >In the end, I think there's nothing better
> >than hinting that folks who care about performance write some tweaks
> >into their serializers.
> 
> As long as everybody here is aware and ok with the fact we are
> breaking existing tools...

It's not breaking any generator or parser tools if you don't want to
optimize. If a server wants to enable an optimized client to consume
its data, it can't use a generic serializer, but it probably wouldn't
anyways. The client's parser needn't change. If the client is written
to stream, it can start streaming as soon as it sees the
ldp:membershipRules arc, which in the case of a cooperative server,
would be written early on.

You may argue with the streaming use case, but if you accept it,
you'll not find anything that works better to address it without
leaving RDF (e.g. using HTTP headers or mime/multipart).


> Alexandre.
> 
> >
> >
> >>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 19:46:52 UTC