- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 11 Oct 2012 16:50:20 +0200
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp-wg@w3.org
- Message-Id: <7F61B657-F606-439D-B6CF-D43C269B9C9F@bblfish.net>
On 11 Oct 2012, at 16:25, Henry Story <henry.story@bblfish.net> wrote: > > On 11 Oct 2012, at 15:59, Andy Seaborne <andy.seaborne@epimorphics.com> wrote: > >> >> >> On 11/10/12 14:29, Kingsley Idehen wrote: >>>> I thinkAndy was saying that that the RDF triples -/containing absolute >>>> URIs/- are the data. >>>> >>> >>> But that simply isn't accurate. >> >> Kingsley - >> >> We can resolve this quite simply - what do the specs say? We can wish for one thing but that does not make it automatically true. >> >> So please reference the spec text - I'm quite happy to be shown to be wrong here, it wouldn't be the first time! > > :-) Ok so please hold on here > > http://www.w3.org/TR/rdf11-concepts/#section-IRIs > [[ > Some concrete syntaxes permit relative IRIs as a shorthand for absolute IRIs, and define how to resolve the relative IRIs against a base IRI. > ]] > > ( They should really say "most") > > The syntaxes can only specify how to resolve a relative URI relative to a base URI. > It is up to other specs to define how you get the BASE url. For example it is > not necessarily the URL you GET, because http allows the server to return a 301 > which changes how you interpret the relative URLs in the graph. If you open a file > on the file system, you don't even use HTTP but the relative URL is then > file:///localhost/... > > > So the same here with POST. With POST *we* define how we get the BASE URL. > We are not the first to do so, as I mentioned previously here is an RFC > which I suppose had a lot of reviews > > http://tools.ietf.org/html/rfc5995#section-3.4 > > Adapted that section to Turtle you get: > > _Request_ > > POST /collection;add-member/ HTTP/1.1 > Host: example.com > Content-Type: text/turtle > Slug: Sample Title > Content-Length: 67 > > @prefix foaf: <http://xmlns.com/foaf/0.1/> > <> a foaf:Document . > > _Response_ > > HTTP/1.1 201 Created > Location: http://example.com/collection/sample%20title > > Good so I think we can multiply the number of RFCs and documents on this subject. The above proves the point because if you then did a GET on http://example.com/collection/sample%20title Then you would end up with the triple <> above being found to be <http://example.com/collection/sample%20title> ( And this works just as well without the Slug header - in that case the server just makes up a random name. ) I should have added Steve Battle's initial excellent post on this thread. http://tools.ietf.org/html/rfc3986#section-5.1 (It is worth looking at this in detail) He wrote quite correctly > > The Relevant Standard: > RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > 5.1. Establishing a Base URI: The base URI of a reference can be established in one of four ways: > 1. Base URI embedded in Content. > 2. Base URI of the encapsulating entity. “If no base URI is embedded, the base URI of a document is defined by the document's retrieval context.” > 3. URI used to retrieve the entity. “if a URI was used to retrieve the base document, that URI shall be considered the base URI.” > 4. Default Base URI (application-dependent) > > However, as a POSTed resource has no real retrieval context it appears to drop right through levels 2 and 3, leaving us with an application dependent choice. > In a linked data context one might then ask , “if a URI _were_ used to retrieve the base document, that URI shall be considered the base URI.” In that case (A) is the most natural solution. Essentially we fall through because we are in the process of CREATING a resource and this resource therefore needs to be created before a base can be given to it. It is the server receiving the POST that is given the role of creating the resource. Henry > > > >> >> Andy >> > > Social Web Architect > http://bblfish.net/ > Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 11 October 2012 14:51:00 UTC