- From: Alexander Dutton <alexander.dutton@oucs.ox.ac.uk>
- Date: Thu, 05 May 2011 10:47:35 +0100
- To: public-lod@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/05/11 09:12, Sebastian Schaffert wrote: > 1. extending the Linked Data principles for updates using REST As far as I can tell, a related idea is already formalised in the Uniform HTTP Protocol for Managing RDF Graphs¹. There are slight differences in that POST is used to augment a graph, and PUT will create if it doesn't already exist (and will return 201 or 200/204 to differentiate). It should also be noted that this spec separates the graph name (i.e. the URL against which updates are performed) from the URI of the resource described by the uploaded RDF. ¹ http://www.w3.org/TR/sparql11-http-rdf-update/ > 2. extending the Linked Data principles for arbitrary content using > MIME mapping and "rel" Content Type You might also be interested in RFC 5988², which specifies a generic way of linking resources (say, the content to its metadata) using HTTP headers. For example, I might HEAD an image and receive: """ Content-Type: image/png Link: </content/logo.png.meta>; rev="http://xmlns.com/foaf/0.1/primaryTopic"; rel="meta" """ At which point I would know to retrieve /content/logo.png.meta. However, as of yet I haven't seen this implemented anywhere. ² http://tools.ietf.org/html/rfc5988 However, the idea is cool, and could be generalised to other values for the rel param (e.g. next, previous). I fear that you would have to standardise the use of 'meta' (through the IETF or W3C), or use a URI (such as foaf:primaryTopic or foaf:primaryTopicOf). Currently defined link types are given at [3]. ³ http://www.w3.org/TR/html401/types.html#type-links > [...] > > or it will return "415 Unsupported Media Format" in case the > content is not available in this MIME type I think you mean 406; 415 is for an unsupported Content-Type request header, not Accept (i.e. the IMT of uploaded content, not requested content). > - if the Accept/Content-Type header is of the form "Accept: > type/subtype; rel=meta", them the redirect URL is > http://localhost/meta/type/subtype/1234; when the URL is requested If it becomes conventional that one can use the rel or rev to retrieve a non-alternative resource (e.g. metadata), then you shouldn't necessarily need to do the redirect. Instead, you'd be sent the related resource with a Content-Location header pointing at its canonical location. > [...] > > - GET http://localhost/resource/1234 in case the resource does not > exist, returns a "404 Not Found", otherwise, a "303 See Other" as > follows: 1. header: "Accept: type/sOn 05/05/11 09:12, Sebastian > Schaffert wrote: 1. extending the Linked Data principles for > updates using REST As far as I can tell, a related idea is already formalised in the Uniform HTTP Protocol for Managing RDF Graphs¹. There are slight differences in that POST is used to augment a graph, and PUT will create if it doesn't already exist (and will return 201 or 200/204 to differentiate). It should also be noted that this spec separates the graph name (i.e. the URL against which updates are performed) from the URI of the resource described by the uploaded RDF. ¹ http://www.w3.org/TR/sparql11-http-rdf-update/ > 2. extending the Linked Data principles for arbitrary content > using > MIME mapping and "rel" Content Type You might also be interested in RFC 5988², which specifies a generic way of linking resources (say, the content to its metadata) using HTTP headers. For example, I might HEAD an image and receive: """ Content-Type: image/png Link: </content/logo.png.meta>; rev="http://xmlns.com/foaf/0.1/primaryTopic"; rel="meta" """ At which point I would know to retrieve /content/logo.png.meta. However, as of yet I haven't seen this implemented anywhere. ² http://tools.ietf.org/html/rfc5988 However, the idea is cool, and could be generalised to other values for the rel param (e.g. next, previous). I fear that you would have to standardise the use of 'meta' (through the IETF or W3C), or use a URI (such as foaf:primaryTopic or foaf:primaryTopicOf). Currently defined link types are given at [3]. ³ http://www.w3.org/TR/html401/types.html#type-links > [...] > > or it will return "415 Unsupported Media Format" in case the > content is not available in this MIME type I think you mean 406; 415 is for an unsupported Content-Type request header, not Accept (i.e. the IMT of uploaded content, not requested content). > - if the Accept/Content-Type header is of the form "Accept: > type/subtype; rel=meta", them the redirect URL is > http://localhost/meta/type/subtype/1234; when the URL is requested If it becomes conventional that one can use the rel or rev to retrieve a non-alternative resource (e.g. metadata), then you shouldn't necessarily need to do the redirect. Instead, you'd be sent the related resource with a Content-Location header pointing at its canonical location. > [...] > > - GET http://localhost/resource/1234 in case the resource does not > exist, returns a "404 Not Found", otherwise, a "303 See Other" as > follows: 1. header: "Accept: type/subtype; rel=content" will > redirect to http://localhost/content/type/subtype/1234; If rel=content, then shouldn't it be a 301 or 307 redirect? (Or indeed, no redirect at all). A couple of ideas: (feel free to ignore them!) As I understand it, you have three classes of resource; a meta-resource that does conneg, the content resource, and the metadata resource. Could you not dispose of the meta-resource, and allow RESTful operations on the other two? You'd still be able to link them with Link headers, as described near the top. You're also introducing a well-known-like convention, in that the starting place is always /resource, and content always has to be served from /content. If I could PUT some RDF metadata to <http://example.org/meta/index> containing a "<http://example.org/meta/index> foaf:primaryTopic <http://example.org/>" triple, then PUT some HTML to <http://example.org/>, it shouldn't be too hard for the server to deduce and add the Link headers between the two, and I would be much freer in how I choose to organise my content and metadata. I have no idea how you might leave URL-choosing to the server (though there have been some discussions about generating unused URIs in triple stores at answers.semanticweb.com⁴). ⁴ http://is.gd/NdjKxO Great work though, and I'd be very interested to see it in action! With kind regards, Alex - -- Alexander Dutton Developer, InfoDev, data.ox.ac.uk Oxford University Computing Services, ℡ 01865 (6)13483 ubtype; rel=content" will > redirect to http://localhost/content/type/subtype/1234; If rel=content, then shouldn't it be a 301 or 307 redirect? (Or indeed, no redirect at all). A couple of ideas: (feel free to ignore them!) As I understand it, you have three classes of resource; a meta-resource that does conneg, the content resource, and the metadata resource. Could you not dispose of the meta-resource, and allow RESTful operations on the other two? You'd still be able to link them with Link headers, as described near the top. You're also introducing a well-known-like convention, in that the starting place is always /resource, and content always has to be served from /content. If I could PUT some RDF metadata to <http://example.org/meta/index> containing a "<http://example.org/meta/index> foaf:primaryTopic <http://example.org/>" triple, then PUT some HTML to <http://example.org/>, it shouldn't be too hard for the server to deduce and add the Link headers between the two, and I would be much freer in how I choose to organise my content and metadata. I have no idea how you might leave URL-choosing to the server (though there have been some discussions about generating unused URIs in triple stores at answers.semanticweb.com⁴). ⁴ http://is.gd/NdjKxO Great work though, and I'd be very interested to see it in action! With kind regards, Alex - -- Alexander Dutton Developer, InfoDev, data.ox.ac.uk Oxford University Computing Services, ℡ 01865 (6)13483 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3CcjcACgkQS0pRIabRbjBDlgCfTDfJI97GoHLhe5TIvRXApLur Q2AAn31AKCSyXzfJQ5e229LbWXX6jFMO =z0pg -----END PGP SIGNATURE-----
Received on Thursday, 5 May 2011 09:47:59 UTC