- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Thu, 11 Mar 2010 11:47:34 +0000
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group WG <public-rdf-dawg@w3.org>
On 09/03/2010 14:50, Chimezie Ogbuji wrote: > My apologies. This seemed to have slipped through the cracks. I think the > situation involving base URIs does need to be clarified in the text, but I > just want to make sure we are on the same page, so I've CC'ed the WG. There > are (at least) two situations that need to be accounted for simultaneously: > > GET /rdf-graphs/employees?graph=../employee/1 HTTP/1.1 > Host: example.com > > PUT /rdf-graphs/employees?graph=../employee/1 HTTP/1.1 > Host: example.com > <?xml version='1.0' encoding='UTF-8'?> > <rdf:RDF > xml:base='http://example2.com/rdf-graphs/employees' > xmlns:rdf='...'> > </rdf:RDF> > > I think we can just (normatively) refer to RFC3986 and clarify with > examples. For the first situation above there is no base specified in the > content (there is no content), so the next level of precedence (Base URL of > the encapsulating entity) would apply. However, I don't think (with HTTP) > that a Base URL can be specified within the request message and 5.1.2 seems > to only apply to a situation where the payload is layered in some way. So, > the next level of precedence would apply (5.1.3. Base URI from the > Retrieval URI). Which means the absolute URI of the graph whose > representation will be retrieved is: > > http://example.com/rdf-graphs/employee/1 > > For the second situation, 5.1.1 (Base URI embedded in content) would > immediately apply since it is at the top of the precedence order and the > payload has a base URI specified in it. The absolute URI of the graph that > will be replaced with the payload is: > > http://example2.com/rdf-graphs/employee/1 > > So for scenarios where the graph parameter is used w/out content with an > explicit xml:base, the user would need to be aware that the Base URI is the > Base URI of the request. > > -- Chime The other case is the base URI for the document received: PUT /rdf-graphs/employees?graph=http://otherserver/consultant/56 Host: example.com <?xml version='1.0' encoding='UTF-8'?> <rdf:RDF .... no base named .... </rdf:RDF> gets a base URI for the parsing of the RDF/XML document of http://otherserver/consultant/56 Andy > > On 3/9/10 8:25 AM, "Andy Seaborne"<andy.seaborne@talis.com> wrote: > >> This thread seems to have petered out. >> >> Do you plan to add something to the doc about base URIs? >> >> I hpoe Steve's analysis is right - the alternative is simply horrible! >> >> Andy >> >> -------- Original Message -------- >> Subject: Re: Base URI in updates? >> Date: Fri, 5 Feb 2010 16:55:11 +0000 >> From: Steve Harris<steve.harris@garlik.com> >> To: Andy Seaborne<andy.seaborne@talis.com> >> CC: SPARQL Working Group<public-rdf-dawg@w3.org> >> >> On 5 Feb 2010, at 16:23, Andy Seaborne wrote: >>> On 05/02/2010 15:53, Steve Harris wrote: >>>> On 5 Feb 2010, at 15:31, Andy Seaborne wrote: >>>> >>>>> This arose because of baseless RDF/XML and wanting to copy them from >>>>> the their original URL to a harvesting store. >>>>> >>>>> What's the base URI when using SPARQL HTTP Update when using remote >>>>> naming (?graph=) >>>>> >>>>> It looks to me like it's the whole of: >>>>> >>>>> http://server/service?graph=http://examples/myGraph >>>> >>>> FWIW, in 4store it's<http://examples/myGraph> in this example. In >>>> our >>>> experiences this more matches user expectations with regard to >>>> relative >>>> URIs. >>> >>> That's what I'd like it to be ... I don't think that HTTP allows it >>> though :-( >>> >>> http://www.ietf.org/rfc/rfc1808.txt >>> 3. Establishing a Base URL >>> >>> .----------------------------------------------------------. >>> | .----------------------------------------------------. | >>> | | .----------------------------------------------. | | >>> | | | .----------------------------------------. | | | >>> | | | | (3.1) Base URL embedded in the | | | | >>> | | | | document's content | | | | >>> | | | `----------------------------------------' | | | >>> | | | (3.2) Base URL of the encapsulating entity | | | >>> | | | (message, document, or none). | | | >>> | | `----------------------------------------------' | | >>> | | (3.3) URL used to retrieve the entity | | >>> | `----------------------------------------------------' | >>> | (3.4) Base URL = "" (undefined) | >>> `----------------------------------------------------------' >> >> In my (not very informed) opinion, 3.2 "Base URL of the encapsulating >> entity" would cover this case, if it was worded correctly in the HTTP >> update spec. >> >> - Steve > > > =================================== > > P Please consider the environment before printing this e-mail > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S.News& World Report (2009). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________
Received on Thursday, 11 March 2010 11:48:13 UTC