- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Fri, 21 May 2010 09:45:36 +0100
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group WG <public-rdf-dawg@w3.org>
> Can you suggest something? What we decide really does need explaining the counter intuitive nature in the doc. I'd like to find a way to make the graph URI the base even if that means contorting things a little - after all, this 3rd party service/graph naming we are using isn't the primary design space of REST anyway. I'd argue that the use of the graph=<abs URI> creates a new URI used to retrieve the entity. When we have http://example/x then adding /y changes the URI used to retrieve the entity (5.1.3) entity from http://example/x to http://example/x/y. So adding ?graph=GraphURI changes the URI used to retrieve the entity (5.1.3) to GraphURI Admittedly weak, but then we are on the boundary of RESTful addressing anyway. Analogous situation: http://example/foaf is an info resource. http://example/foaf#me is not contained in that info resource so this change of reference to a completely different context does exist. Andy On 18/05/2010 4:11 PM, Chimezie Ogbuji wrote: > Ok, thanks for clarifying. Comments below > > On 5/18/10 4:29 AM, "Andy Seaborne"<andy.seaborne@talis.com> wrote: >> Concretely: >> If relative IRI<x> is in the payload for the request >> PUT /rdf-graphs/employees?graph=http://otherserver/consultant/56 >> what is the proposed resolved absolute IRI? > > In the current form, the resolved absolute IRI would be > > /rdf-graphs/employees/x > >> >> If it's not >> >> http://otherserver/consultant/x >> >> then it's going to be quite confusing because the same message sent to >> different service endpoints but the same graph=IRI has different >> absolute IRIs in it. > > Going back to diagram of resolution precedence: > > | .----------------------------------------------------. | > | | .----------------------------------------------. | | > | | | .----------------------------------------. | | | > | | | | .----------------------------------. | | | | > | | | | |<relative-reference> | | | | | > | | | | `----------------------------------' | | | | > | | | | (5.1.1) Base URI embedded in content | | | | > | | | `----------------------------------------' | | | > | | | (5.1.2) Base URI of the encapsulating entity | | | > | | | (message, representation, or none) | | | > | | `----------------------------------------------' | | > | | (5.1.3) URI used to retrieve the entity | | > | `----------------------------------------------------' | > | (5.1.4) Default Base URI (application-dependent) | > `----------------------------------------------------------' > > The only way the absolute IRI would be otherwise would be if (5.1.2) > applied. This would require an intuitive interpretation of the following > (with respect to the URI embedding mechanism we are using for indirect > reference): > > [[[ > For a document that is enclosed within another entity, such as a message or > archive, the retrieval context is that entity. Thus, the default base URI of > a representation is the base URI of the entity in which the representation > is encapsulated. > ]]] > > I can understand how the behavior without 'filling in' 5.1.2 for the HTTP > RDF protocol would be counter intuitive for documents where the graph IRI is > embedded in the query component but the payload does not have an embedded > Base, but I can't think of a cohorent piece of text that describes how the > payload can be said to be 'enclosed' or 'encapsulated' within (presumably) a > representation of http://otherserver/consultant/56. Can you suggest > something? > > -- Chime > > > =================================== > > 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. >
Received on Friday, 21 May 2010 08:46:06 UTC