[sc34wg3] Subject Locators

Bernard Vatant sc34wg3@isotopicmaps.org
Fri, 10 Jun 2005 19:00:39 +0200

> On Jun 9, 2005, at 1:48 AM, Patrick Durusau wrote:
> >
> > ... as Fielding makes clear in his dissertation the REST
> > model (see section Representations, 6.2 REST Applied to
> > URI, 6.2.1 Redifinition of Resource, and 6.2.1 Manipulating
> > Shadows) relies upon the notion that only a representation of the
> > resource is ever returned.


> Yep! IOW, with HTTP/URI you can never ever address a representation
> and redefining the definition of what a URI is just won't do the
> trick. IOW, the whole idea of a subject locator makes no sense on the
> Web.

I guess Jan meant to write *you can never ever address a resource, only a representation*
... otherwise I'm lost.

That said, I think I now agree with you both. I've come with time to the conclusion that
TMDM "subject locators", as well as XTM "resourceRef", and the distinction between
"addressable" and "non-addressable" subjects should all be deprecated. Although I had hard
time explaining the difference between the two internally in Mondeca, the most relunctant
ones having eventually surrendered ("I you say so, you are the guy who knows").
Such distinctions draw a very thin, arbitrary line which is very difficult to explain, and
is in the long run unsustainable. I've thought during a long time, as Steve P. argued in
his very clever paper on Web Identity crisis, that it was a killer distinction, but now I
think it's useless at best.
If you want to make clear that the URI you use identifies an information resource rather
than an organization, make it clear using the topic type! It's up to the TM author to take
the responsibility to decide which resource is identified by which URI in its TM. Unless
the URI has been published as a PSI, and the PSI editor has a kind of authority to say :
this URI identifies an information resource, don't use it to identify a company.

So if A declares:

<topic id="foo">
		<subjectIndicatorRef xlink:href="http://xmlns.com/foaf/0.1/Organization"/>
		<subjectIndicatorRef xlink:href="http://www.mondeca.com"/>

And B declares:

<topic id="bar">
		<subjectIndicatorRef xlink:href="http://www.mondeca.com"/>

B seems at least as explicit as C

<topic id="bar">
		<resourceRef xlink:href="http://www.mondeca.com"/>

"A" says this URI provides a good indication/representation of what the organization is,
since it's an organization.
"B" says this URI provides a good indication/representation of what the homepage is, since
it's a homepage.

All the point of Patrick is that you can't catch more the "is-ness" of a homepage than the
"is-ness" of an organisation. You think you can because something pops up on your screen
when you type the URI in your browser, something that you call the homepage to make it
Sure, certainly A and B do not agree on what http://www.mondeca.com identifies. Big deal.
Neither is right nor wrong, unless the owner of the domain name have some opinion on this
URI meaning and has published it somewhere as a PSI. In this very case, I'm pretty sure
it's not the case (neither for opinion nor publication).
Agreed, merging A and B will be a mess. Maybe. Not sure. But that's the responsibility of
the merger. As suggested a while ago in a debate somewhere (here or on topicmapmail, not
sure) certainly at merging time the merger will check a certain number of things to avoid
the merged topic map to be a mess. If its ontology somehow declares that "Organization"
and "Homepage" are disjoint classes, the merging process will at least warn of
inconsistency ...

Well, that's enough to start a war I guess :))



Bernard Vatant
Senior Consultant
Knowledge Engineering

"Making Sense of Content" :  http://www.mondeca.com
"Everything is a Subject" :  http://universimmedia.blogspot.com