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

On Tue, 2011-03-15 at 14:44 -0400, Jonathan Rees wrote:
> 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...

I was talking about content *type* -- not Content-location.  

> 
> > 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.

True.  But I think it is much more likely to be a problem if it is in
the content than in the header, because the degree of mushiness is
different.  A header is very specific.  It doesn't depend on media types
or whether you're using OWL inferencing, etc.  

OTOH, how would such a "distinguishing mark" be included in the content?
Presumably as an RDF triple.  But exactly how would that RDF triple be
stated?  In what serialization?  And under what semantics?  I think this
would start falling into the same problems as with content type.


-- 
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 19:14:28 UTC