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

In short form, the ambiguity is the characteristics of the 
resource identified based on the physical or observable 
characteristics of the resource being measured (in this 
position, a URI is itself a document or term (equivalent 
names).  Shorter, the question is what can be inferred with what 
probability.   This notion violates the opaqueness of 
URIs in principle but not in practice.  It also means 
that uncertainty is variant by resource, that this is 
irresolvable, but that as most information retrieval 
systems for unstructured data have proven, a similarity 
metric is good enough for indexed systems.

Uncertainty is proportional to semantic loading.

Note that this is true of all systems that rely on 
mapping physical characteristics that can be measured 
to ontologies for some event.  The uncertainty decreases 
over a series of observations if no other force changes 
the environment (why uncertainty is proportional to 
semantic loading).  The past is not always informative. 
It proabably is.  If an event changes the environment, 
uncertainty increases because the semantic load increases. 
That is why a near property (under local semantic control) 
is a better bet.

Ambiguity is a problem.  It varies locally.  There is no 
answer to that because it is a fixed property of the 
system itself (conflation of name and location - forget 
identity; it is a function value, not an intrinsic property).

len


From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
Norman Walsh

/ 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]

Received on Thursday, 28 April 2005 20:05:21 UTC