W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

Re: Comments on draft "baseline" httprange-14 replacement

From: Jonathan A Rees <rees@mumble.net>
Date: Sat, 18 Feb 2012 09:04:17 -0500
Message-ID: <CAGnGFM+4zex_0bB-kMm0qHyWJV2a+=WyKrYX-SVDEV8BPpqEhg@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: www-tag@w3.org
On Fri, Feb 17, 2012 at 5:11 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 2/17/12 3:54 PM, Henry S. Thompson wrote:
>> But the document has to use_some_  word in the place it currently uses
>> 'meaning', doesn't it?  Seems to me_whatever_  word is used will raise
>> hackles in some quarters, so the present approach, which uses it and
>> then (in section 7) explicitly foregrounds the difficulties attendent
>> on doing so, is the best that can be done.
> Re. Linked Data context:
> 'meaning' could be replaced with 'description' since this is all about
> identifiers that resolve to descriptor resources.
> A descriptor resource is a document that describes the referent of a
> de-referencable HTTP URI, where said URI names (identifies) the subject of
> the descriptor resource.

Actually here you have replaced "meaning" with "referent", not with
"description".  "Description" sounds like a replacement for "URI

The adjective "nominal" is still necessary since, according to your
definition, you could follow some protocol, get some information, and
that information might not actually describe the referent. We need a
qualified term for the information you actually get, regardless of
whether it in fact serves the purpose it's expected to serve (the
latter judgment being left up to the client). In an earlier version I
had "putative" but decided "nominal" was better.

I think it's important to limit the scope to URIs somehow, thus "URI
documentation" or "URI descriptor" or "URI definition". "Carrier" is
also necessary since the representation you get can have all sorts of
things other than specifically information related to the single URI -
consider the case where the URI is part of an ontology written in a
single document, or just a minor aspect of the overall content of an
HTML page, or is accompanied by formatting, scripts, advertising, etc.
So I think we have to be talking about a "nominal URI dxxx carrier" in
any case. Just a matter of what "xxx" is.

You may have noticed that some of my earlier analysis attempted to
restrict the scope to "referential use" of URIs, as you suggest, and
avoid the broader scope of "meaning". My experience was that was
unnecessarily limiting and generally not very successful, but I'm open
to changing this back.

I'm slightly open to changing "documentation" and "meaning" but I
think this is not urgent at this point in the process. What I want now
is to get other people involved in helping build consensus regarding
substantial topics like the treatment of 200 responses and
/.well-known/ , as these would actually matter to performance and
hosting. Let's look at the terminology options later, as separate
issues, since terminology choice does not alter the protocol.

(It looks as if I'll have to set up an issue tracker for the project,
to help ensure that my own judgments don't get in the way of consensus
building, but I want to put that off a bit.)

> A descriptor resource is a kind of information resource.
> We are looking for words that clearly explain the following indirection:
> SubjectName->SubjectDescriptorResourceAddress->SubjectDescriptionRepresentation
> (an eav/spo graph pictorial) .

With some methods, such as MGET, 209, LSID, and conneg, there is no
"SubjectDescriptorResourceAddress", only a representation, so making
indirection through a URI-named resource a necessary part of the
problem statement would be preemptive. The overall relation
"representation Z is a NUDC for URI U" needs to be the operative
primitive here (regardless of what you call it), or else these
solutions get locked out.


> --
> Regards,
> Kingsley Idehen
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Saturday, 18 February 2012 14:04:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:13 UTC