Re: httpRange-14: some dimensions of space of positions

[OFFLIST -- though feel free to share with the TAG if you like]

Hi Henry,

Overall, I found your summary very useful, though
it appears to lead up to issue httpRange-14 without
actually touching on the key issue itself.

I'll try to explain what I mean.

Firstly, I agree with your position, that ambiguity
is a problem and should be differentiated by syntactically
distinct URIs (and I think this is quite clearly spelled
out in AWWW as well, and also the view reflected in
the core semantic web standards).

However, I see ambiguity, and how to avoid it,
to be a side issue to httpRange-14.

Whether or not a given URI is used ambiguously
is disjunct from whether or not it contains a
hash. Both hash and slash URIs can be used
ambiguously. And internal (syntactic) differentiation
can be used to distinguish between both hash and slash
URIs.

Thus, your summary provides a very clear and useful
expression of the context of the debate, but
does not address the key issue of the debate.

Issue httpRange-14 presumes, I think, that URIs
are unambiguous insofar as their intended meaning
ascribed by the creator/owner of the URI, and
thus, I think it's fair to say that httpRange-14
presumes your view:

    Ambiguity:    is a problem,
    Differention: yes,
    Signal:       internally

The real question is not about ambiguity and
how it is signaled, but about whether, e.g. if
the owner of a URI is crystal clear about the
meaning of a URI, and all users of that URI
accept and understand the intended meaning and
use the URI per its intended meaning (i.e.
there is no ambiguity), can a URI
without a hash validly identify an RDF property,
or a dog, or the concept of slightly watery
fudge pudding.

If http: URIs are constrained to only identify
"Information Resources" (which, as you know, I
think is entirely unnecessary and damaging to
the future of the web), users can still use such
URIs ambiguously to refer to *different* information
resources. Thus, choosing hash over slash does
in any way resolve issues of potential ambiguity.
However, choosing slash over hash faciliates
technologies such as URIQA which allow for users
to clarify, from the URI authority, what the intended
usage is, and thus allow users to act responsibly.

Ambiguity is a separate issue that will exist
regardless of the outcome of issue httpRange-14.

Issue httpRange-14, in a nutshell, is about whether
one can presume anything about a resource based on
whether its http: URI contains a hash or not. Tim
would argue yes. I (and most others) would argue no.

In either case, the URI could be used ambiguously
and in an antisocial and irresponsible manner.

Best regards,

Patrick


On Apr 26, 2005, at 18:36, ext Henry S. Thompson wrote:

>
> In trying to come to a clear and concrete statement of my own views on
> the matter, I've struggled to articulate the space of positions
> already staked out, as it were.  I thought there might be some value
> in setting out what I've understood to be several of the features
> which discriminate between different positions.
>
> 1) The OFWeb (Old-Fashioned Web) primarily uses http: URIs as a means
> to an end, namely retrieving encoded character streams with some kind
> of rendering semantics, the encoding and semantics typically being
> signalled in the http header.  The SemWeb primarily uses http: URIs as
> an end in themselves, as the constituents of RDF triples i.e. as names
> for things and relationships between them.  Some people believe that
> at least in the case where http: URIs being used in the SemWeb could
> be used in the OFWeb, an ambiguity arises.  Contrast the use of
> "http://www.w3.org/" in
>
>   <rdf:Description rdf:about="http://www.w3.org/TR/webarch/">
>     <dc:publisher rdf:resource="*http://www.w3.org/*"/>
>   </rdf:Description>
>
> and
>
>   <rdf:Description rdf:about="*http://www.w3.org/*">
>     <dc:creator>
>      <rdf:Bag>
>       <rdf:li>Ian Jacobs</rdf:li>
>       <rdf:li>Susan Lesch</rdf:li>
>      </rdf:Bag>
>     </dc:creator>
>   </rdf:Description>
>
> Feature 1: Ambiguity -- Either it *doesn't exist*, or it exists but
>            *isn't a problem*, or it exists and *is a problem*
>
> 2) Stipulate that Ambiguity exists, and that at least it _might_ be a
> problem, then the question arises as to whether one or more explicit
> ways/conventions/mechanisms should be adopted to differentiate between 
> the
> two uses of http: URIs in any particular case.
>
> Feature 2: Differentiation -- *Yes* we should make it possible to
>            differentiate, or *no* we shouldn't
>
> 3) Stipulate that we should differentate, then the further question
> arises as to how to do so.  I have identified three kinds of signal
> one could use, there may well be others:
>
> Feature 3: Signal -- Either use *far context* (e.g. information in the
>                                              relevant schema)
>                      or *near context* (e.g. the name of the enclosing
>                                       element or attribute in the
>                                       XML representation, c.f. Topic 
> Maps
>                                       resourceRef vs. 
> subjectIndicatorRef)
>                      or *internally* (e.g. # convention, tdb: and wpn:
>                                     proposals)
>
> I can characterize my own position as
>
>   [Ambiguity:    is a problem,
>    Differention: yes,
>    Signal:       internally]
>
> I'll leave argumentation to a subsequent message -- I'd be interested
> to hear _first_ from others whether this characterisation is accurate
> and helpful.  If not accurate but at least potentially helpful,
> suggested improvements are of course in order.
>
> ht
> -- 
>  Henry S. Thompson, HCRC Language Technology Group, University of 
> Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is 
> forged spam]
>

Received on Wednesday, 27 April 2005 05:52:55 UTC