Re: Base URI in updates?

 > 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