[sc34wg3] Subject Locators

[Murray Altheim]

Jan Algermissen wrote:
> On Jun 13, 2005, at 7:14 PM, Lars Marius Garshol wrote:
>>* Jan Algermissen
>>|
>>| If you intend the semantics of your resource to be 'a fixed document
>>| instantiation (bits and bytes)' then use the URI of the resource to
>>| reference it. There is no point in using the URI as a subject
>>| locator since the resource already represents the bits and bytes.
>>
>>You argued in earlier posts that the bits&bytes and the resource
>>itself are two different things. So clearly there is a distinction to
>>be made here. What's then wrong with making the distinction?
>>
>>| The whole distinction between subject locator and subject indicator
>>| simply does not make sense on the Web.
>>
>>Now you really are just repeating yourself. I'd like to know *why* you
>>think this.
> 
> Because on the web you only have a single addressing context. Saying  
> that some URI is a subject locator does not imply that the resource
> the URI points to is document-like at all. IOW, you cannot alter the 
> underlying definition of URI by introducing additional addressing 
> semantics. 

Unless I'm mistaken about what you're talking about, this seems to
be really putting looking at the whole issue at the wrong level. We
aren't altering the underlying definition of *URI*, nor are we
changing the addressing semantics. We don't even need concern
ourselves with what URIs mean, with addressing semantics. In XTM
we're making clear the *link* semantics. Big difference.

We use URIs as an addressing context only because on the Web that
is the way that addressing happens. That doesn't mean that in XTM
we can't decide to add additional semantics to the link, which is
precisely what we're doing. If XLink hadn't had limitations on
parent-child link element structures, we could have expressed this
in xlink:role attributes. This has *nothing whatsoever* to do with
REST. What REST is about is completely orthogonal to Topic Maps.
We aren't adding semantics to the URI, we're adding semantics to
the link, stating a link role, i.e., we're stating the what or why
of we're making such a link. We're stating that a given online
resource either:

   is itself our subject (<resourceRef>)
   identifies another Topic as our subject (<topicRef>)
   contains content that indicates our subject (<subjectIndicatorRef>)

> You seem to think that using a URI
> as a subject locator gives you the ability to say: "this URI refers  
> to a some conecpt
> that is in fact a document (bits and bytes)." But the URI identifies  
> what it identifies,
> regardless of addressing context.

We can characterize a link any way we like. We use the URI as the
addressing method. We're not overloading the URI itself with the
link semantics.

> And IMHO this becomes lucidly clear once you put a URI into your  
> browser's location bar
> (and immediately loose any addressing conetxt) because HTTP just does  
> not provide for
> communicating an addressing conetxt to the server.
> 
> This does not mean that one cannot build information system that do  
> allow such destinctions. But with HTTP you just don't get it because
> it has been deliberately excluded.

We have built an information system that allows those distinctions,
quite deliberately. Again, we don't have to care about HTTP. That's
just plumbing.

I don't see how the myriad and ongoing arguments within the W3C
about the nature of URIs has anything to do with this. Roy's
dissertation is interesting, but it's not worthy of religious
adoration -- it's an attempt to describe what URIs are about.

We don't need to be interested in the nature of URIs per se,
only in using them to link up things within a Topic Map. We're
operating at an entirely different level in defining explicit
semantics for our little world of Topic Maps. URIs are just
part of the plumbing. Because we can explicitly define things,
even if the REST of the world futzes around for another ten
years on the definitions of URIs, it makes no difference:
within a TMA we have defined what our links mean. If someone
changes out the pipes, we don't have to care. Thank god, as
only a masochist would want to keep track of the W3C's stance
on URIs.

Murray

......................................................................
Murray Altheim                          http://www.altheim.com/murray/
Strategic and Services Development
The Open University Library
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

       The moment you come to trust chaos, you see God clearly.
       Chaos is divine order, versus human order. Change is
       divine order, versus human order. When the chaos becomes
       safety to you, then you know you're seeing God clearly.
                                               -- Caroline Myss