Re: please review issue-57 document draft before Tuesday telcon

On Tue, Mar 15, 2011 at 2:17 PM, David Booth <david@dbooth.org> wrote:
> On Tue, 2011-03-15 at 11:39 -0400, Jonathan Rees wrote:
>> On Tue, Mar 15, 2011 at 10:44 AM, Jonathan Rees <jar@creativecommons.org> wrote:
>> > On Tue, Mar 15, 2011 at 9:16 AM, David Booth <david@dbooth.org> wrote:
>> >> 7.  Sec 5.7 "Overload dereference, and use response properties to
>> >> distinguish the two cases" mentions "two cases", so I looked back to see
>> >> what the "two cases" are.  I think the two cases are these:
>> >>
>> >> Given a document d that is hosted at URI u and describes subject s, what
>> >> conventions should be used to refer to d and s?  I.e., for a given
>> >> dereferenceable URI u, what conventions should be used to refer to IR(u)
>> >> and WS(u)?
>> >
>> > No, the two cases are, does u refer to IR(u), or to WS(u)?
>> > I thought this is what the first paragraph says... not sure how to
>> > make it more clear.
>>
>> OK, I've tried to fix this problem. Check the latest. The section
>> still needs some work, and could really benefit from input from
>> someone who is proposing any solution similar to this.
>
> Thanks, the latest text is clearer.  But I think this one will have be
> subdivided into at least three options for how the "distinguishing mark"
> that would indicate that u should refer to WS(u) instead of IR(u) could
> be indicated:
>
> 1. By the Content-type.  Since *any* content type could be viewed as a
> serialization of RDF, it would have to sanction specific content types
> to have this special meaning, which would inhibit the growth of new RDF
> serializations.

So the rule is: if a response to GET u has a Content-location: header,
then u refers to WS(u), and the target of the Content-location: is
IR(u)?  That doesn't make any sense - Content-location: is used in
other contexts, and at best the Content-location: target will be a
different information resource that shares some versions
(representations) with IR(u) - it won't be IR(u) itself.

Is someone seriously proposing this? The only information I have on
this is a set of email messages and blog posts that I don't understand
- I haven't yet seen a complete proposal.

Really looking for help with this...

> 2. In some other HTTP header.  This option would suffer from the same
> drawback as 303: that publishers cannot always control their server
> configurations.

Yes, and Content-location: has exactly the same drawback.  I still
can't see why anyone would prefer adding meaning to Content-location:
over Link:.

Just trying to understand.

> 3. In the returned content itself.  But this would be non-monotonic, as
> a reader that did not initially understand the content would take the u
> to refer to IR(u), but later when greater knowledge is gained through
> semantic extensions
> http://www.w3.org/TR/rdf-mt/#MonSemExt
> those assertions would have to be revoked.

But that also holds for any HTTP header as well. Not sure what the
different is, except maybe the amount of expertise that a client has
to have.

Best
Jonathan

>
> --
> David Booth, Ph.D.
> http://dbooth.org/
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
>
>

Received on Tuesday, 15 March 2011 18:45:13 UTC