LDPNext

A wish list for LDP.Next

In the scope of the current activity there is some potential extension work we we might want to consider. Please extend the following list.

Discussed at F2F5 and tallied.

1 How to PATCH ?

Related Issues

• 17 changesets as a recommended PATCH format

2 Embedded representations (a/k/a inlining)

When retreving a representation of a resource, a minimal expectation of the server is that it returns all the triples it where the addressed resource is found in the subject position (entity view). The server may also choose to inline other triples where the targeted resource is found in the object position. The baseline practice is that the client navigates to related resources to find out about them. However, to improve the efficiency of this interaction, it might be useful for client to instruct the server to provide inline representations of related resources. This requirement is similar to the functionity that OData provides with its 'expand' query option [1].

Related Issues

• 38 Filtered Representations and Inlining
• 58 Property for asserting that complete description of members is included in LDPC representation

3 Filtering collections

Related to embedded representation is collection filtering. Collection filtering is a way of filtering a partial view of a collection based on some kind of filtering criteria.

4 Richer Containers

An ongoing (and persistent) discussion within LDP is that of containers. When a resource is considered to be contained inside another resource, there might be an expectation from a client that when the 'parent' resource is DELETEd, then the contained resources also get DELETEd. Furthermore, they might this behaviour to recursively apply. If this is not addressed in today's LDP, then LDP.next might want to provide the necessary extensions to define additional semantics around containers, including recursive deletion.

Related Issues

• 25 Weak aggregation and strong composition in containers
• 59 Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

5 Globbing or inlining (with filtering)

To save round trips, a server may decide to offer the possibility to aggregate all the resources from a given container into a single graph, and then return this graph to the client. For instance, doing `curl -H"Accept:text/turtle" https://example.org/posts/*` would return a single graph containing all the triples from the resources in /posts/. This is especially useful when using predefined resource names, such as dates: 2014-04-01-file1, 2014-04-01-file2, etc., and then do `curl -H"Accept:text/turtle" https://example.org/posts/2014-04-01-*`.

The client should also be allowed to specify the types of resources it wants to aggregate, in order to avoid irrelevant triples in the returned graph. For instance, specifying the resource type to be "sioc:post" would then filter out all the corresponding ACL triples.

6 Application APIs

It could be said that LDP currently facilitates CRUD style data manipulation. However ...

Related Issues

• 26 Creation Model

7 Snapshots

Allow client to get a URL for a never-changing copy of some resource at some point in time

Possible design: request MAY include

Prefer: create-snapshot

and response, even if not requested, MAY include:

Link: <....> rel=snapshot

If the server can provide the snapshot URL at no cost, it SHOULD do so even if client client didn't request create-snapshot. The client should only say create-snapshot if it's really going to use it, since it might be somewhat expensive.

Might be called: frozenVersion, staticCopy, etc.

8 Client-initiated paging

Allow the client to say it wants the first or last page, maybe of the snapshot, without additional roundtrips.

Might be done with a general follow-relations mechanism, like:

 Prefer: follow-rel="snapshot last"

If it says "Preference-Accepted: follow-rel" can it just use 200 OK? It can only do this to clients who asked for it, so what possible harm is there? (answer: need to be very careful about caching.)

9 Client-controlled page sizes

Something like:

Prefer: max-page-megabytes=10

10 Client-controlled page sorting

Something like:

Prefer: member-sort predicates="http:// ...  "

11 Client-controlled container filtering

Allow clients to download only a selection of items from a container.

Possible design: ClassContainer

12 Container Inclusion

Allow clients to set up containers which automatically contain the items in other containers, including containers on other servers.

Use case: microblogging app user subscribes to many feeds, but needs to see recent posts (across all feeds) in one simple operations

Possible design: ClassContainer

13 Connection to SPARQL datasets

Allow clients to find out what SPARLQ end point it can use to query/update resources en masse.

Easy part: resources can include a Link: rel=sparqlEndPoint

Hard part: how can you tell which resources are going to be in that end point's dataset and which are not, without dereferencing each resource? This is a security issue -- what graph names can you trust the end-point will be authoritative for?

Possible design: per-origin SPARQL End Point, instead of per-resource:

http://example.com/.well-known/sparql-end-point

This server would be understood to be authoritative for all graphs names starting with "http://example.com/".

14 Guidance for PUT

Allow clients to know what URLs to use for PUT if they want to add to a given container.

Maybe Link rel=containedItemURLPattern except that its value would be a regexp not a URL.

15 Client-Controlled Inlining

Allow client to GET some/all triples in each contained resource, in one GET.

Might be done with Prefer, or with a URL template, or, ... what?

Something like:

Prefer: inline predicates="http:// ...  "

16 Datasets

When client requests inlining, allow it to request that the triples are returned as part of a dataset, with triples in named graphs corresponding to the resources they came from.

Link rel or Prefer?

There might also be other metadata, like last-modified time, in this case presented as RDF triples instead of HTTP headers.

17 Push

Allow other systems (clients and other servers) to get notified/updated when various state changes occur.

18 POST Multiple

Allow client to simultaneously POST multiple resources, in case they are cross-linked and/or need to appear at the same moment, because of things waiting for them.

19 PATCH Multiple

Allow client to update multiple resources in one atomic, isolated transaction.

20 Back Links

Provide some way for server 1 to tell server 2 that it holds content which links to content on server 2 (like trackback, webmention), and some way for clients to ask server 2 about this information.

21 Crowd CDN

Provide a way for untrusted servers to cooperate to form a trusted Content Distribution Network (CDN).

Use Case: an interesting but not wealthy individual has a data source which becomes extremely popular. With a crowd cdn protocol, some of the followers could act as distribution nodes. (Proof of concept: bittorrent. The worst a malicious node can do is slow down some of the flow.)

22 Access Control

Provide a way that clients can tell a server which authenticated client identities are allowed to perform various LDP operations on particular resources or resource groups.

23 Provenance

Allow clients to see the provenance of resources and triples. Who added this triple? When? Why?

Particularly interesting in situations where the server might be contributing triples, too, perhaps as the result of logical inference.

Possible design:

 Link: rel=provenance

where the link points to a named graph in a dataset which is the root of a tree of provenance information, all within that dataset.

24 Linked-Data Authentication

Allow clients to securely identify themselves as being identified a particular IRI, so IRIs can be used (in the obvious linked-data way) as accessor-identifiers during authorization reasoning.

Possible design: WebID-TLS, http://www.w3.org/People/Sandro/userpage-auth

25 Test Dispenser

Allow clients to create temporary resources to explore/test what a particular server is capable of doing, eg for running a test suite against a server.

Possible design: a resource clients can POST to, where created resources are automatically deleted 1 hour after creation time

26 Efficient delivery of changes

Provide a means for a server to share with a client an efficient way to communicate the changes (add to container, removed from, or changed) of resources within a given container.

Possible design: OSLC TRS, http://open-services.net/wiki/core/TrackedResourceSet-2.0/

27 Containers as SPARQL endpoint

Everything is in the title :-)

28 Attaching a shape for constraints

Currently there is no formal way to express what a server expects on POST/PUT (create) or PUT/PATCH (update). It would be useful to adopt the output of the yet-to-be-completed "RDF Shapes" working group.

29 LDP transactions

Provide support for transactions in LDP applications. There are several transaction models proposed for RESTful applications as summarized here. These models allow to do atomic transactions ensuring consistency when multiple clients read/write LDP resources in parallel. We can adapt one or more RESTful transaction models in LDP so that LDP applications can support transactions.