[sc34wg3] Subject Locators

[Murray Altheim]

Jan Algermissen wrote:
> On Jun 13, 2005, at 9:34 PM, Murray Altheim wrote:
>>Jan Algermissen wrote:
>>>On Jun 13, 2005, at 8:52 PM, Lars Marius Garshol wrote:
>>>
>>>>* Murray Altheim
>>>>|
>>>>| Exactly -- we are using the URI as the means of addressing, but  
>>>>the
>>>>| link is what carries the semantics. We are as I just wrote
>>>>| characterizing our links. What URIs mean or do or say or eat for
>>>>| breakfast has *nothing* to do with this.
>>>>
>>>>Yep.
>>>
>>>When you have a resource that has the intended semantics of some   
>>>person 'Jim Smith' and NOT some kind of document about him;
>>>what is the meaning of
>>><topic id="t1">
>>>   <subjectIdentity>
>>>     <resourceRef xlink:href="http://example.org/persons/Jim_Smith"/>
>>>   </subjectIdentity>
>>></topic>
>>>then?
>>>The topic represents Jim Smith - right?
>>>
>>
>>If you're using <resourceRef> the Topic is *never* flesh and blood.
>>In the example you provide, it is the web page (resource) returned
>>by a traversal of the link provided. The subject is the resource,
>>hence "resourceRef". If you intend the Topic's subject to be something
>>about Jim, you'd use <subjectIndicatorRef>, which means that the
>>resource indicates the subject.
> 
> Hmm..this contradicts Lars who said the linking context does *not*  
> affect what the URI identifies.

 From my read of this confusing conversation, I'd let Lars Marius
decide whether there's any issue here. He was trying to react to
your use of language. So, now with three of us, let's not pick
too closely on how someone else has expressed something. He might
have used very different language if he wasn't trying to inter-
communicate with you. From my understanding of where Lars Marius
is coming from, I don't think there's a contradiction.

> If the intended semantics of a resource (REST sense!) are flesh  
> and blood, no <resourceRef> can ever change that.

Then your example was flawed.

Only you are concerned with REST. I could give a flying rat's
body part about REST right now. For XTM we have defined what
a <resourceRef> means, and nothing that a URI is or was or
leaves on the carpet can change what we mean by our links (REST
sense or not!). We (I repeat: WE) have defined what we mean when
we say something. It's not up to TimBL or Roy or anyone else.
To give up our power to state what we mean would be silly. We
can define what we mean by syntax and stick to it. The W3C isn't
even a standards body. This is an ISO mailing list. What ISO
decides has more force than either the W3C or Roy's dissertation,
which is just a dissertation. In no world I live in does anyone
have a right to constrain what I *mean* by something when I say
it. Same with XTM. We got together, defined a syntax, and defined
what it meant. If ISO standardizes that, we at least have that.

Put it another way: the "semantics"* of a link is something we're
completely able to specify. We have done so in both TopicMaps.Org
and ISO. Full stop.

* I.e., "meaning" to anyone that doesn't think too highly of
   their intellectual abilities, not to suggest you in
   particular, just trying to bring the absurd profundity of
   that word back to reality. The "Web With Meaning" wouldn't
   have sold as well to the DARPA officials or Sci. American.
   Anyone dealing with "semantics" must know what they're
   talking about. Not surprisingly, the word is actually being
   misused in this case.

>>This is all spelled out in some
>>detail within the XTM 1.0 Specification, so I'm not sure where the
>>confusion lies, unless you're spellbound by REST semantics and have
>>begun to confuse REST with Topic Maps.
> 
> Well, XTM uses URIs, so I'd say XTM *is* bound.

You somehow are equating URI semantics with REST semantics with
link semantics. REST is not a standard, has no official bearing
on anything whatsoever (it's so far just a religious movement),
and *again*: we don't need to concern ourselves with whatever
the semantics of a URI are. This is the big mistake of the W3C,
in trying to overload URIs. It's why they've wasted hundreds of
thousands of hours of peoples' time on this. URIs are just a way
of addressing something. We don't need to deal with that here.
Ten years from now we might not be using URIs, but we can still
be using XTM. We have defined a set of link semantics for XTM
and they're completely suitable, and will be, on the web, off
the web, and post-Web.

>>As I mentioned, whatever REST
>>is about it's nothing to do with Topic Maps.
> 
> True...as long as you do not do 'Topic Maps for the Web'. As I said  
> before:
> you cannot simply ignore the semantics of the stuff that XTM builds  
> upon.

XTM *is* "Topic Maps for the Web" and we'll do whatever we damned
well please. I don't know where you've gotten this mistaken notion
that REST is somehow dictating to the Web community what it does
with URIs. REST is just one potential way of making them more than
that, but nothing Roy can do or say can alter the semantics of the
links people create (most of them are implicit, in XTM they're not).
You might note that REST came out more than a decade after we've
already been using URIs. It's not likely that anyone will pay much
attention to it. It rather defines "academic," a bit like the
retroactive semantics for RDF. If the IETF or W3C were to go and
alter what URIs are meant to mean, they'd be off their nut (we'll
see). The rest of the Web has always used them as addresses, and
will ignore any dictates on what the URIs mean, as they should.

I didn't crawl into a cave in 1999 with Elizabeth Clare Prophet;
I'm not likely to alter how I use URIs, nor will 99.9% of the Web
community. We use them to point to something, nothing more. And
everything XTM does is at a linking level, not a URI level, so the
entire subject is moot. If REST interests you, great. But it has
nothing to do with XTM.

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