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

Hello Henry,

> 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've just been reflecting on this and wonder where you have missed one
further possible alternative, which is information arising from an
attempt to dereference. In the case of http (which is what we are
speaking of) the status code and http headers (eg. Content-type and
Location) may be informing. Harry Halpin mentions in one of his messages
the notion of a 404+ [1]. I have also wondered about the legitmacy of
using a 30x redirection that redirects to a distinct information
resource which describes or depicts (rather than represents) what was
originally referenced. Tim BL also mentions this possiblity briefly in
[2].

"Near-context" and "internal" approaches can of course be 'resolved'
without further retrival. "Far context" and "dereferencing" may not be
resolvable from the reference and/or its surrounding context alone.

One other thought is that there may be more than one answer... in that a
strategy to resolve an ambiguity might be multi-faceted.

Regards

Stuart
--
[1] http://lists.w3.org/Archives/Public/www-tag/2005Apr/0097
[2] http://www.w3.org/DesignIssues/HTTP-URI.html
"So, we could change HTTP to make this work. We could make a new form of
redirect, 343 Abstract Object, please see . . ., which would tell the
client that the thing requested was abstract, and would suggest a
document to read about it. This avenue of argument is still outstanding.
We could take it. It isn't the status quo, but we could make changes in
HTTP if the community felt that this was they way to go."



> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Henry S. Thompson
> Sent: 26 April 2005 16:37
> To: www-tag
> Subject: httpRange-14: some dimensions of space of positions
> 
> 
> 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 Tuesday, 3 May 2005 16:32:56 UTC