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

Clarifying the space of possible positions is *always* useful.
On Thu, 28 Apr 2005, Dan Connolly wrote:
>> Feature 1: Ambiguity -- Either it *doesn't exist*, or it exists but
>>            *isn't a problem*, or it exists and *is a problem*
>
 	It can exist and *can be a problem* in some cases. The Semantic 
Web makes as its central claim that a URI is a global identifier that can 
be shared across various boundaries. It is as yet unclear when mixing the
SemWeb and the OFWeb exactly how to maintain that notion of identity.

>> 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. A few techniques: URI Scheme (tdb://, wpn://), new MIME type 
(noninformationresource), a new type of error message (404+, 
non-information resource not network retrievable), a new form of 
representation (this web-page is *really* Pat Hayes, not just a 
web-page), some RDF vocabulary (objectDenotes). All of these have
possible benefits and problems.

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

 	OWL is good, but still misses the point sometimes. If you just
make a new OWL statement that says

http://www.example.org/PatHayes ex:Denotes "Pat Hayes"
doesn't really work, cause sometimes Pat Hayes is Patrick Hayes,
and "Pat Hayes" sure looks like an arbitrary string to me :)

http://www.example.org/PatHayes ex:Denotes 
http://www.example2.org/PatrickHayes
doesn't really work, since it just moves the problem to another
potentially ambiguous URI.

http://www.example.org/PatHayes ex:Denotes
http://www.example.org/PatHayes
where the second use of the URI means "the non-information resource this
web-page is about" seems to break the idea of a URI being a global 
identity. It's using one URI for two different things, breaking RDF graph
merging etc.

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

It's a good ad-hoc practice but it does seem to overload the poor # 
operator in a weird way.

  I can characterize my own position as

    [Ambiguity:    is a problem,
     Differention: yes,
     Signal:       near context]

I think solving it at the URI scheme level is the one fine way to do it, 
but possibly also troublesome (isn't Google also somehow defined by the 
exsistence of http://www.google.com). The cleanest way I can think of is 
just to define a RDDL like vocabulary for the representation to return 
that tells a user in good-old HTML that this http:// URI is about a 
non-information resource. Then we can use content negotiation to also
serve relevant RDF at the URI. After all, we gotta put those RDF 
statements *somewhere*.




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

-- 
 				--harry

 	Harry Halpin
 	Informatics, University of Edinburgh
         http://www.ibiblio.org/hhalpin

Received on Friday, 29 April 2005 14:53:20 UTC