User:Rcygania2/Pagination

1 Use case for ISSUE-33: Pagination for non-container resources

1.1 Use case: Retrieve a large resource description in multiple parts

This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request.

In a social network scenario, we have personal profiles where a person may have other people as contacts.

Note that it is not uncommon for users to have a very large number of contacts. This leads to a very large resource description, especially if some basic information about the contacts is included as well:

The size of this representation may be so large that retrieval in a single HTTP request is impractical.

Note that in the example here, there is no container/containment relationship between the related resources (people). Therefore, LDP's container mechanism with its paging facility cannot be used to solve this problem.

The server may therefore provide a facility that's independent from the container facility in order to retrieve the resource in multiple parts. We assume that it's going to be only the values of some particular properties (foaf:knows in this case) that are broken out into separate parts. Note that the details of the design here are purely a straw man:

It's not really the resource description that's being paginated, but the values of a particular property.

The server is in charge of pagination. Some servers may not use pagination. The server decides how large the pages are.

This facility needs to be available both for “incoming” and for “outgoing” properties.

It's up to the server implementation to decide the structure of the page URLs. It could be </users/34523/contacts/2> or <contacts.php?user=34523&page=2>. The server communicates this URL structure by providing links in the representation (ldp:nextPage in the straw man example).

Perhaps the server may decide to include some values (e.g., the “first page” of foaf:knows values) directly in the description of the originally requested user resource. This means that clients would “see” at least some contacts with just a single HTTP request.