@@ -58,91 +58,78 @@ HTTP/1.1 200 OK
58
58
<http://www.w3.org/ns/posix/stat#size> "780" .
59
59
```
60
60
61
- #### Globbing (inlining on GET )
61
+ #### Globbing (` GET ` the merged RDF graph of a container )
62
62
63
63
** Note: this feature is _ at risk_ of being
64
64
[ changed] ( https://github.com/solid/solid-spec/pull/148 )
65
65
or [ removed] ( https://github.com/solid/solid-spec/pull/151 ) .
66
66
Please join the discussion.
67
67
Code depending on this will still work for now.**
68
68
69
- We have found that in some cases, using the existing LDP features was not
70
- enough. For instance, to optimize certain applications we needed to aggregate
71
- all RDF resources from a container and retrieve them with a single GET
72
- operation. We implemented this feature on the servers and decided to call it
73
- "globbing". Similar to [ UNIX shell
74
- glob] ( https://en.wikipedia.org/wiki/Glob_(programming) ) , doing a GET on any URI
75
- which ends with a ` * ` will return an aggregate view of all the resources that
76
- match the indicated pattern.
77
-
78
- For example, let's assume that ` /data/res1 ` and ` /data/res2 ` are two resources
79
- containing one triple each, which defines their type as follows:
80
-
81
- For * res1* :
69
+ To optimize certain applications,
70
+ this specification defines a single ` GET ` operation
71
+ that provides access to an aggregation of the RDF resources in a container.
72
+ We refer to this feature as _ globbing_ ,
73
+ since it provides a subset of the functionality
74
+ offered by the [ UNIX shell glob] ( https://en.wikipedia.org/wiki/Glob_(programming) ) .
75
+ Consider a container to which the user has _ Read_ access,
76
+ which will have a URL ending in ` / ` .
77
+ If we append a ` * ` to that URL (so it ends in ` /* ` ),
78
+ we obtain the URL of a resource that,
79
+ in response to a ` GET ` request,
80
+ returns the [ RDF graph merge] ( https://www.w3.org/TR/rdf-mt/#graphdefs )
81
+ of all of the container's direct child resources
82
+ that are available in an RDF format
83
+ and for which the user has _ Read_ access.
84
+ Resources with syntax errors can be ignored or be partially included,
85
+ but they do not cause a failure.
86
+ The response can contain additional metadata about the container,
87
+ such as the list of resources.
88
+
89
+ For example, consider a container ` /data ` that contains the following resources:
90
+ - ` resource1.ttl `
91
+ - ` resource2.ttl `
92
+ - ` hidden3.ttl `
93
+ - ` resource4.txt `
94
+
95
+ The user performing the request had read access to ` /data ` ,
96
+ ` resource1.ttl ` and ` resource2.ttl ` ,
97
+ but not to ` hidden3.ttl ` .
98
+ Let's assume that ` /data/resource1.ttl ` and ` /data/resource2.ttl `
99
+ contain one triple each:
82
100
83
101
``` ttl
84
102
<> a <https://example.org/ns/type#One> .
85
103
```
86
104
87
- For * res2* :
88
-
89
105
``` ttl
90
106
<> a <https://example.org/ns/type#Two> .
91
107
```
92
108
93
- If one would like to fetch all resources of a container beginning with ` res `
94
- (e.g. ` /data/res1 ` , ` /data/res2 ` ) in one request, they could do a GET on
95
- ` /data/res* ` as follows.
96
-
97
- REQUEST:
98
-
99
- ``` http
100
- GET /data/res* HTTP/1.1
101
- Host: example.org
102
- ```
103
-
104
- RESPONSE:
105
-
106
- ``` http
107
- HTTP/1.1 200 OK
108
- ```
109
- ``` ttl
110
- <res1>
111
- a <https://example.org/ns/type#One> .
112
-
113
- <res2>
114
- a <https://example.org/ns/type#Two> .
115
- ```
116
-
117
- Alternatively, one could ask the server to inline * all* resources of a
118
- container, which includes the triples corresponding to the container itself:
119
-
120
- REQUEST:
109
+ Then a request to ` /data/* `
110
+ will return a serialization of the [ RDF graph merge] ( https://www.w3.org/TR/rdf-mt/#graphdefs )
111
+ of the datasets contained in ` resource1.ttl ` and ` resource2.ttl ` :
121
112
122
113
``` http
123
114
GET /data/* HTTP/1.1
124
115
Host: example.org
125
116
```
126
117
127
- RESPONSE:
128
-
129
118
``` http
130
119
HTTP/1.1 200 OK
131
120
```
132
121
``` ttl
133
122
<>
134
123
a <http://www.w3.org/ns/ldp#BasicContainer> ;
135
- <http://www.w3.org/ns/ldp#contains> <res1 >, <res2 > .
124
+ <http://www.w3.org/ns/ldp#contains> <resource1.ttl >, <resource2.ttl > .
136
125
137
- <res1 >
126
+ <resource1.ttl >
138
127
a <https://example.org/ns/type#One> .
139
128
140
- <res2 >
129
+ <resource2.ttl >
141
130
a <https://example.org/ns/type#Two> .
142
131
```
143
132
144
- Note: the aggregation process is not currently recursive, therefore it will not
145
- apply to children containers.
146
133
147
134
### Alternative: using SPARQL
148
135
@@ -392,4 +379,4 @@ Servers SHOULD send a WAC-Allow response header on HEAD and GET, with a value li
392
379
``` http
393
380
WAC-Allow: user="read write append control",public="read"
394
381
```
395
- In general, the format is ` user=" ` + user-permissions = ` ",public=" ` + public-permissions + ` " ` . User-permissions and public-permissions should both be space-separated lists, containing a subset of [ 'read', 'write', 'append', 'control'] . If 'write' is present then 'append' should also be present.
382
+ In general, the format is ` user=" ` + user-permissions = ` ",public=" ` + public-permissions + ` " ` . User-permissions and public-permissions should both be space-separated lists, containing a subset of [ 'read', 'write', 'append', 'control'] . If 'write' is present then 'append' should also be present.
0 commit comments