W3C home > Mailing lists > Public > www-tag@w3.org > April 2005

httpRange-14: some dimensions of space of positions

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 26 Apr 2005 16:36:55 +0100
To: www-tag <www-tag@w3.org>
Message-ID: <f5bsm1dczxk.fsf@erasmus.inf.ed.ac.uk>

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 rdf:about="*http://www.w3.org/*">
      <rdf:li>Ian Jacobs</rdf:li>
      <rdf:li>Susan Lesch</rdf:li>
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:

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.

 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 Tuesday, 26 April 2005 15:37:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:45 UTC