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

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

From: Dan Connolly <connolly@w3.org>
Date: Thu, 28 Apr 2005 16:34:52 -0400
Message-Id: <ae307e4b7550f302edb83520da6ed7ab@w3.org>
Cc: www-tag <www-tag@w3.org>
To: ht@inf.ed.ac.uk (Henry S. Thompson)

On Apr 26, 2005, at 11:36 AM, 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*

I'm not sure what my position on that is.

There's an idealization of the Web in which ambiguity doesn't exist,
kinda like newtonian mechanics where we ignore relativistic effects.

I'm not sure whether differences of opinion between parties
should count as ambiguity or what.

> 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

Yes.

> 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 think OWL is a standardized (and good) far-context mechanism.
far in the sense of possibly-far, i.e. arbitrarily-near-or-far...
it may be nearby or widely known/cached.

I think that the # convention is a good-practice.
i.e. folks that use hashless URIs for things
other than information resources are making things
more difficult either for themselves or for others.

> 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.



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 28 April 2005 20:34:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:34 GMT