Re: optimizing container pages serialization to enable streaming

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.

> (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...

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.
>>>
>>
>

Received on Monday, 11 November 2013 18:44:25 UTC