W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

Re: Base URI in updates?

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Tue, 18 May 2010 11:11:04 -0400
To: "Andy Seaborne" <andy.seaborne@talis.com>
cc: "Steve Harris" <steve.harris@garlik.com>, "SPARQL Working Group WG" <public-rdf-dawg@w3.org>
Message-ID: <C8182648.11A02%ogbujic@ccf.org>
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 Tuesday, 18 May 2010 15:13:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:42 GMT