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

On Tue, Mar 15, 2011 at 3:13 PM, David Booth <david@dbooth.org> wrote:
> 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.

Oops! Sorry.

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

I agree, but headers are as hard to deploy as 303, so this fails
Harry's hosted-solution test. If we're going to incompatibly change
200s, we'd better get the maximum possible value out of it.

Content-type: {some flavor of RDF or OWL} might work.
The number of RDF-or-OWL types is getting to be pretty large, so I
agree this is a problem. I think we're up to ten or eleven - and there
are certain to be more. Maybe there could be a registry.

And if text/html is in the set due to RDFa then I'm not sure what the
point would be - the IR case would not be enabled in the majority of
cases, so you might as well assume it *never* works, and always use
clumsy-notation for IRs. Maybe Ian has in mind doing this with only
one or a few of the RDF media types?

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

My question was, what if you got an RDF document (in any of the eleven
different RDF media types) in which the URI in question didn't even
occur?  Could the URI revert to naming IR(u)? That's the case I had in
mind by putting the mark in the content - the "mark" would be the URI
itself - and that's what I thought Ian and Harry were suggesting with
the "just take it at face value" approach.

We need someone who can champion the  "just take it at face value"
approach; I don't know how to make it sound viable. I had been hoping
Nathan could play that role... We could recruit someone now, or just
publish and hope someone turns up afterwards to defend the position.

I'm likely to rearrange section 5.  Chimera, <u> != IR('u'), and "face
value" (with "it depends" as a variant) are all closely related. I'm
having a hard time untangling the three.

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 21:24:21 UTC