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

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 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>

I don't think this is quite the right way to cast the problem. For one
thing, where's the ambiguity here? You've made statements about a
resource. If I know that Ian and Susan didn't create the W3C, I can
conclude that you've made conflicting statements, but *nothing* that
anyone decides can prevent users from making conflicting statements.

I think httpRange-14 is about the stipulation that you can examine a
URI and determine intrinsic properties of the resource it identifies
(for example, that if it uses the http: scheme and does not contain a
fragment identifier, it must identify an "information resource").

Webarch generally discourages agents from inferring properties about a
resource by examing the URI that identifies it[1] but it does say that
"in practice, a small number of inferences can be made because they
are explicitly licensed by the relevant specifications".

So the question becomes, what are the relevant specifications and do
they license the stipulation?

I think the relevant specifications here are RFC 3986 and RFC 2616.

RFC 3986 is really about the generic syntax of URIs. It mentions http:
almost exclusively in examples and by my reading makes no attempt to
impose any intrinsic properties on any resources identified by any
URIs.

RFC 2616 says "The 'http' scheme is used to locate network resources
via the HTTP protocol."

From here we wander off into the weeds arguing about what "locate"
means and what constitutes a "network resource". A body of practical
experience, including various sorts of gateways and systems that allow
you to interact with physical objects in the real world through http:
URIS, comes to bear which makes it hard to get consensus on the answer
to this question.

| 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 think this characterization is a great idea. I encourage others to
follow-suit. My position is:

  [Ambiguity:    unsure
   Differention: yes, if ambiguity is a problem
   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.

Well, I don't know if what I said above is argumentation or suggested
improvement :-)

                                        Be seeing you,
                                          norm

[1] http://www.w3.org/TR/webarch/#uri-opacity

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.