Define Prefer header URI for compact collection representation

[barmintor]

Turtle and JSON-LD are the only two required serializations in the LDP specification, and both include a compact syntax for ordered collections of statement objects. The specification should propose a Prefer header for requesting this compact form (rather than blank nodes for first and rest).

[zimeon]

I think the turtle () syntax and JSON-LD @list type are both interesting explorations of what RDF-with-native-lists might be like, that remain compatible with rdf:List. It would be good to allow and be compatible with systems leveraging these ideas.

Some way of requesting compact syntaxes with "implementations MAY support" seems quite reasonable. I assume the defining extra parameters for the Prefer: return=representation; ... header would make sense and would be compatible with other preference expressions in the Fedora API (some of which might be applied at the same time).

The question that stops me giving wholehearted support is: "Is it likely that implementations would want to support turning compact syntax on or off? Would they instead support either one syntax or the other? If they are based around a stack using the compact syntax, would there ever be a reason to prefer to non-compact syntax?"

[escowles]

I think the issue is that the compact syntax requires some overhead. For example, unless you had special knowledge of the triples, you would have to process all the triples in memory in order to make sure you had all the objects of a given predicate to group together in the compact syntax.

So I see this prefer header as a way for the client to indicate that it's willing to accept the tradeoff: more processing overhead and probably loading all the triples into memory, in order to have the conveniences of the compact syntax.

I don't know why a client would prefer the non-compact syntax. You should get the same triples when you parse it — just grouped differently or in a different order.

[zimeon]

I think we have decided not to move ahead with this feature (and PR #285) for the API recommendation. I propose that we create a defer label for this issue and close the PR.