Re: Base URI in updates?

(admittedly being a bit lost in the whole discussion here, still some minor comment):

"In situations where there is no Base URI in the payload and a graph IRI is
embedded, the RDF document that represents [AWWW] the networked RDF
knowledge identified by the embedded graph IRI SHOULD be considered the
retrieval context (5.1.2) [RFC3986].  Thus, the default base URI is the base
URI of that RDF document."

Sounds fine to me... Maybe a stupid question on something which smells 
like a corner case... what if the given graph IRI is a relative IRI itself
would that be possible/allowed??

[...]

"The identified secondary resource **may be some portion or subset** of the
primary resource, some view on representations of the primary resource, or
some other resource defined or described by those representations. "

Again, maybe stupidly lacking HTTP details, would

s/**may be some portion or subset**/**may be a fragment**/

be ok?

Axel

On 21 May 2010, at 14:13, Chimezie Ogbuji wrote:

> On 5/21/10 4:45 AM, "Andy Seaborne" <andy.seaborne@talis.com> wrote:
>> What we decide really does need explaining the counter intuitive nature
>> in the doc.
> 
> Yes.
> 
>> 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.
> 
> True
> 
>> I'd argue that the use of the graph=<abs URI> creates a new URI used to
>> retrieve the entity.
> 
> What if the new URI isn't resolvable? I.e.,
> 
> PUT /rdf-graphs/employees?graph=tag%3Aogbujic%40ccf.org%3A2010/consultant/56
> Host: example.com
> <?xml version='1.0' encoding='UTF-8'?>
> <rdf:RDF
> .... no base named ....
> </rdf:RDF>
> 
> We can't say that tag:ogbujic@ccf.org:2010/consultant/56 was used to
> 'retrieve' anything.
> 
>> 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.
> 
> Ok.  I agree that 1) we are on the boundary of RESTful addressing and 2) we
> want to support this behavior.  I think we can go about it with the
> following wording that explains an intepretation of 5.1.2 since I don't
> think 5.1.3 would work in all cases:
> 
> "In situations where there is no Base URI in the payload and a graph IRI is
> embedded, the RDF document that represents [AWWW] the networked RDF
> knowledge identified by the embedded graph IRI SHOULD be considered the
> retrieval context (5.1.2) [RFC3986].  Thus, the default base URI is the base
> URI of that RDF document."
> 
>> Analogous situation:
>> 
>> http://example/foaf is an info resource.
>> http://example/foaf#me is not contained in that info resource
> 
> This is off topic, but according to the definition of a URI fragment,
> http://example/foaf#me *could* be contained in that IR:
> 
> "The identified secondary resource **may be some portion or subset** of the
> primary resource, some view on representations of the primary resource, or
> some other resource defined or described by those representations. "
> 
> -- 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, 25 May 2010 12:51:25 UTC