- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Thu, 30 May 2013 20:32:24 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello. regarding ISSUE-67: Full container membership without pagination we cannot over-constrain servers here. servers have the right and should have the freedom to respond with whatever they feel is a good default, when somebody GETs the LDPC URI. following the usual affordance model, what a server then should do is to allow clients to maybe GET something else, if they want to. any kind of hardcoded URI parameter is a well-known anti-pattern, so instead of doing this, we might just reuse what RFC 5005 defines (and which is available via http://www.iana.org/assignments/link-relations/link-relations.xml for the whole web to reuse). the pattern you seen frequently happening on the web is as follows: - GET URI gives you whatever the server thinks is a good default. no guarantee of completeness, and very often a rather small subset sorted in a relevant manner, which in many cases means by date (but it's up for the server to decide that). - if the server supports it, relative links are provided in the representation, using the standardized link relations. these allow relative navigation (first, next, previous, last), but not absolute navigate (jump to page 42). - if the representation is complete, a flag will indicate that it is complete, so that clients don't have to guess whether it is complete or not. what's missing (afaict) is a standardized link relation that allows non-complete versions (such as individual pages) to a complete version (if the server decides to expose such a version). it might make sense to only expose such a link for reasonably-sized containers, or only to clients that have privileged access rights. regardless of the practicalities of exposing links to potentially very large containers, we can either include such a link in the LDP vocabulary (closing ISSUE-67 with the resolution to standardize such a link, and we could even register it with IANA, if we want to), or we don't (and then ISSUE-67 is closed by saying "there is no standardized to expose such an affordance"). if would of course always be up to the service to decide whether it wants to actually provide such a link at runtime, or not. personally, since this is about linked data and maybe having processes that transfer large amounts of data back and forth and want to do this effectively, maybe having a standardized way would be good, instead of leaving it unspecified. cheers, dret.
Received on Friday, 31 May 2013 00:33:13 UTC