Warning:
This wiki has been archived and is now read-only.
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.
Contents
- 1 How to PATCH ?
- 2 Embedded representations (a/k/a inlining)
- 3 Filtering collections
- 4 Richer Containers
- 5 Globbing or inlining (with filtering)
- 6 Application APIs
- 7 Snapshots
- 8 Client-initiated paging
- 9 Client-controlled page sizes
- 10 Client-controlled page sorting
- 11 Client-controlled container filtering
- 12 Container Inclusion
- 13 Connection to SPARQL datasets
- 14 Guidance for PUT
- 15 Client-Controlled Inlining
- 16 Datasets
- 17 Push
- 18 POST Multiple
- 19 PATCH Multiple
- 20 Back Links
- 21 Crowd CDN
- 22 Access Control
- 23 Provenance
- 24 Linked-Data Authentication
- 25 Test Dispenser
- 26 Efficient delivery of changes
- 27 Containers as SPARQL endpoint
- 28 Attaching a shape for constraints
- 29 LDP transactions
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.