Difference between revisions of "User:Rcygania2/Pagination"

From Linked Data Platform
Jump to: navigation, search
(Use case: Retrieve a large resource description in multiple parts)
 
Line 47: Line 47:
 
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.
 
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:
+
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:
  
 
<pre>
 
<pre>
Line 98: Line 98:
 
Assumptions:
 
Assumptions:
  
 +
* 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.
 
* 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.
 
* 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).
 
* 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.
 
* 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.

Latest revision as of 13:38, 14 March 2013

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

See ISSUE-33

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.

GET /users/alice HTTP/1.1
Host: example.com
Accept: text/turtle

@prefix foaf: <http://xmlns.com/foaf/0.1>.

</users/alice> a foaf:Person;
  foaf:name "alice";
  foaf:knows </users/bob>, </users/charlie>.

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:

GET /users/34523 HTTP/1.1
Host: example.com
Accept: text/turtle

@prefix foaf: <http://xmlns.com/foaf/0.1>.

</users/34523> a foaf:Person
  foaf:name "alice";
  foaf:knows </users/24352>, </users/75257>, </users/64245>,
    </users/27539>, </users/11076>, </users/73953>, </users/32965>,
    </users/69646>, </users/43275>, </users/65923>, </users/89002>,
    …

</users/24352> a foaf:Person; foaf:name "bob".
</users/75257> a foaf:Person; foaf:name "charlie".
</users/64245> a foaf:Person; foaf:name "dan".
…

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:

GET /users/34523 HTTP/1.1
Host: example.com
Accept: text/turtle

@prefix foaf: <http://xmlns.com/foaf/0.1>.

</users/34523> a foaf:Person
  foaf:name "alice";
  ldp:paginatedValues [
    ldp:property foaf:knows;
    ldp:nextPage </users/34523/contacts/1>;
  ].
GET /users/34523/contacts/1 HTTP/1.1
Host: example.com
Accept: text/turtle

@prefix foaf: <http://xmlns.com/foaf/0.1>.

</users/34523>
  foaf:knows </users/24352>, </users/75257>, </users/64245>;
  ldp:paginatedValues [
    ldp:property foaf:knows;
    ldp:nextPage </users/34523/contacts/1>;
  ].

</users/24352> a foaf:Person; foaf:name "bob".
</users/75257> a foaf:Person; foaf:name "charlie".
</users/64245> a foaf:Person; foaf:name "dan".
GET /users/34523/contacts/2 HTTP/1.1
Host: example.com
Accept: text/turtle

@prefix foaf: <http://xmlns.com/foaf/0.1>.

</users/34523> foaf:knows </users/27539>, </users/11076>, </users/73953>, </users/32965>.
</users/34523> a foaf:Person; foaf:name "emily".
</users/11076> a foaf:Person; foaf:name "fred".
</users/73953> a foaf:Person; foaf:name "gabe".

Assumptions:

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