RE: Does a URI identify a "web page"?

Hello Micah

Happy to see someone bite on that one :))

|Would it be possible for you to compare and contrast the topic maps
|(resourceRef vs. subjectIndicatorRef) with the RDF technique of direct
|statements vs. blank nodes?

I'm not sure I will take the challenge to do that right now, but
certainly I can express your two below example in XTM syntax, and
certainly *you* could express it in RDF. I suppose the first one would
use a direct statement, because it is a statement about the resource and
the second a blank node, because it's a statement about a non-adressable
subject. Is that correct? 

|The distinction seems to me to in some ways parallel making a direct
|statement in RDF
|( was-last-modified-on January-28-2003)

This case is very clear, because the subject represented by the URI
seems well identified as a resource. There is a single possible

In XTM it would look like the following - yes, a little verbose ... 
note that <topic id="last-modification-date"> has to be present, and
defined, somewhere in the same document.

<topic id="dubinkoinfo">
		<resourceRef xlink:href=""/>
			<topicRef xlink:href="#last-modification-date"/>
|and indirectly stating something through a blank node
|(There exists a person, we'll call him "Micah")
|("Micah" has-a-web-page-at

Well, this is more difficult, because the relationship between the
subject above represented by "dubinkoinfo" and the subject "Micah" has
no clear semantics to me. What do you want to express? 

"dubinkoinfo" is a subject indicator for ("represents") "Micah"? [1]
"Micah" is the webmaster of "dubinkoinfo"? [2] 

[1] ... the simplest (simplistic?) interpretation

<topic id="micah">
		<subjectIndicatorRef xlink:href=""/>

This is saying that the web page provides to human beings going there a
non-ambiguous indication of whoever "Micah" *is* ... whatever that means

[2] ... or more specific relationship

		<topicRef xlink:href="#webpage-webmaster"/>
        		<topicRef xlink:href="#webmaster"/>
      		<topicRef xlink:href="#micah"/>
       		<topicRef xlink:href="#webpage"/>
      		<topicRef xlink:href="#dubinkoinfo"/>

Note that Topic Map expressivity allows to explicit neatly either one,
and in fact many more kinds of relationship between "Micah" and whatever
subject you have chosen this URL to identify. 
|When expressed in simple terms as here, it seems that the two
approaches are
|strikingly similar. (though I haven't ever seen it expressed like this

Yes they are. But topic maps have all the built-in conceptual and
syntactic power to express those subtle semantic distinctions :)

|I'll leave it to those experts in topic maps/RDF to comment (or refute,
|stand behind) this observation.

... next one please :))


Bernard Vatant
Knowledge Engineering
Mondeca -

OASIS Published Subjects Technical Committee

The Semantopic Map

|-----Original Message-----
|From: Bernard Vatant []
|Sent: Saturday, January 25, 2003 3:14 PM
|Subject: RE: Does a URI identify a "web page"?
|I've been attracted to this debate because the noise it makes has been
|heard as far as in my original topic maps land :)
|Maybe those things have been already told here - anyway. This is more
|less a copy of a message I send to OASIS XRI list.
|To well understand what follows, first remind that the notion of
|is the most generic in topic maps. It's "whatever anyone cares to speak
|about", be it abstract, concrete, generic or individual, real or
|imaginary, network-retrievable or not...
|The topic maps standard clearly provides distinct ways to deal with
|so-called "addressable" subjects (network-retrievable resources) and
|"non-addressable" subjects (abstract entities or physical individuals).
|Both can be identified by URIs. Let's see how it works using the
|of David Booth at
|The URL "" can be used in topic maps land to identify
|two subjects among the four that David quotes: subject 2. and subject
|Subject 2. is not addressable. It is a certain "concept of love", that
|is supposed to be expressed, defined or at least "indicated" to human
|users when they de-reference the URL.
|Subject 3. is exactly "whatever the hell you get when you de-reference
|the URL". Of course the actual content of that can evolve with time,
|because the conception of love expressed by the editor of that resource
|can evolve when (s)he advances in age :)) So it's not a document, and
|the issue how to identify Subject 4 (the document which is actually
|there when I get to the address) is not really addressed in that
|Think about an exemple like
|I guess the document is changing, unless I live on the Moon, but the
|subject indicated is well identified: "today's weather in my place".
|How do you express that in topic maps land?
|Let's start by subject 3. Let's define a topic to represent this
|This is basic in topic maps. When you want to speak about a subject,
|represent it by a topic. Cool :)
|How do I express that my subject *is* a resource?
|In XTM syntax, I will write the following:
|  <topic id="subject3">
|	<subjectIdentity>
|		<resourceRef xlink:href=""/>
|	<subjectIdentity>
|  </topic>
|Now for subject 2. I define a topic of which identity is "indicated" by
|the same URI:
|  <topic id="subject2">
|	<subjectIdentity>
|		<subjectIndicatorRef xlink:href=""/>
|	<subjectIdentity>
|  </topic>
|In that case, TM terminology is that is for subject 2
|a "subject identifier", and the resource itself is a "subject
|So the same URL is used to identify two distinct subjects, but with no
|ambiguity, due to the syntactic context in which it is used.
|Bottom line: a URL, like any other kind of character string, does not
|identify any subject by itself, but can be used as an identifier if you
|provide a clear and unambiguous identification process. And since
|process can be different, the same string can be used different ways to
|identify different things. This is not specific to URLs, it is the same
|with whatever naming or identification system. "2003-01-24" is only a
|character string, and it does not identify the current day, out of
|Hope that helps

Received on Wednesday, 29 January 2003 04:08:27 UTC