- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Thu, 31 Jan 2013 09:47:08 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello henry. On 2013-01-31 13:28 , "Henry Story" <henry.story@bblfish.net> wrote: >Why not have your service document do something like this ><> xyz:service <http://ldp.example/> . ><http://ldp.example/> a ldp:Container . >And then if you want to specify the media types available on that you >could add ><http://ldp.example/> xxx:mime "application/atom+xml", "text/turtle" . >If it wants to link to another service it could write: ><> xyz:service <http://ldpng.example/> . ><http://ldpng.example/> a ldpng:Container . >See nothing special here. that works on the semantic web (where you expose things via RDF), but not on the web (where you have to live with HTTP's uniform interface). let's look at a more condensed example: a server providing a variety of collection management services at the same URI, just because this is possible and it's kind of cool to always use the same URI for the collection, regardless of whether it's accessed through LDP or AtomPub or LDP-NG. a client would access that URI with a GET or POST, and then could say what it accepts in an HTTP Accept header (or what it POSTs in a Content-Type header), listing media types to allow the server to respond appropriately. the scenario here is the same as in my example about the service document, but you really have no vocabulary other than media types, because that is what HTTP uses (http://tools.ietf.org/html/rfc2616#section-14.1). cheers, dret.
Received on Thursday, 31 January 2013 14:59:46 UTC