RE: [xri] [Fwd: Re: Clarifying what a URL identifies (Four Uses of aURL)]

[Bernard Vatant <bernard.vatant@mondeca.com>]

Hello folks


Let me jump into the debate from the topic maps - published subjects
viewpoint. 

First remind that the notion of subject 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
"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 example
of David at
http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm

The URL "http://x.org/love"; can be used in topic maps land to identify
two subjects among the four that David quotes: subject 2. and subject 3.

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


Think about an exemple like http://meteo.org/myplace/today
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. You define a topic to represent this subject.
This is basic in topic maps. When you want to speak about a subject, you
represent it by a topic. Cool :)

How do you express that my subject *is* a resource? 
In XTM syntax, I will write the following:

<topicMap>
  <topic id="subject3">
	<subjectIdentity>
		<resourceRef xlink:href="http://x.org/love"/>
	<subjectIdentity>
  </topic>
</topicMap>

Now for subject 2. I define a topic of which identity is "indicated" by
the same URI:

<topicMap>
  <topic id="subject2">
	<subjectIdentity>
		<subjectIndicatorRef xlink:href="http://x.org/love"/>
	<subjectIdentity>
  </topic>
</topicMap>

In that case, TM terminology is that http://x.org/love is for subject 2
a "subject identifier", and the resource itself is a "subject
indicator".

If both URL and resource are stable, and declared by the publisher of
x.org to be here to stay and used for purpose of identification, they
can now be considered as respectively "published subject identifier" and
"published subject indicator" for subject 2.

So the same URL is used to identify two subjects, but with no ambiguity
in either case, due to the syntactic construct.

Bottom line: a URL, like any other kind of character string, does not
identify any subject "per se", 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 "per se" identify the current day, out
of context. 

As for subjects 1. and 4. in David's example, Subject 1 can be dealt
with a "reified name". The subject is the character string. Topic maps
do not provide explicit ways to deal with that - maybe Lars Marius has
more to say about it.

Subject 4 is more tricky, and I agree with David it is difficult to be
dealt with using URLs. You can't use the same string to identify several
subjects of the same type using the same identification process. That
would simply break the whole notion of identification.

Hope that helps

Bernard

============================================
Bernard Vatant
Knowledge Engineering
Mondeca - www.mondeca.com
OASIS Published Subjects Technical Committee
www.oasis-open.org/committees/tm-pubsubj
============================================

|-----Original Message-----
|From: Wachob, Gabe [mailto:gwachob@visa.com]
|Sent: vendredi 24 janvier 2003 01:23
|To: 'xri@lists.oasis-open.org'
|
|The issue of how to use URIs to identify abstract or real-world things
(as
|opposed to network locations) is a very hot topic these days (this
week!)
|at
|the W3C. The TAG list is having very heated discussions on this topic.
|
|Specifically, there is a document discussing the ambiguities of using
HTTP
|urls in different contexts (or rather, any single URI scheme in
multiple
|contexts).
|
|http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm
|
|Definitely a fascinating line of thought that dovetails in some ways
with
|our motivations. Specifically, relative to this document, I think we'd
|describe the XRI effort as a "name indicates meaning" approach to
|identifying real world resources.
|
|Also see
http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis.htm
|which reviews rfc2396 (defining URIs) with a similar critical eye
(long).
|
|	-Gabe
|
|> -----Original Message-----
|> From: Peter C Davis [mailto:peter.davis@neustar.biz]
|> Sent: Thursday, January 23, 2003 7:19 AM
|> To: 'xri@lists.oasis-open.org'
|> Subject: [xri] [Fwd: Re: Clarifying what a URL identifies
|> (Four Uses of
|> a URL)]
|>
|>
|> This prompts me to raise an issue, which i think is incompletely
|> addressed with laisons to other standards bodies:
|>
|> I think we need formal language (in the requirements draft) which
|> ecourages the research into complimentary and conflicting resource
|> expression methodologies.
|>
|> Having said that, todays mention of outside entities questioning the
|> need/benefits for this TCs output (which drives clarification in the
|> requirements draft), goes a long way to this end.  Clear
|> articulation of
|> the gaps in current resource identifier notations should be
|> included in
|> the introduction.
|>
|> The W3C TAG, in particular, is likely to keep a scepticle eye, until
|> these shortcommings are well laid out.
|>
|> --- peterd
|>
|> -------- Original Message --------
|> Subject: Re: Clarifying what a URL identifies (Four Uses of a URL)
|> Resent-Date: Thu, 23 Jan 2003 06:42:20 -0500 (EST)
|> Resent-From: www-tag@w3.org
|> Date: Thu, 23 Jan 2003 11:17:48 +0000
|> From: Graham Klyne <GK@ninebynine.org>
|> To: Tim Berners-Lee <timbl@w3.org>
|> CC: Sandro Hawke <sandro@w3.org>, www-tag@w3.org
|> References: <200301212127.h0LLRNA15108@wadimousa.hawke.org>
|>
|>
|> At 10:02 PM 1/22/03 -0500, Tim Berners-Lee wrote:
|>  >One *can* introduce a new system with a different design
|>  >and argue its merits. Sandro has designed an alternative
|>  >system http://www.w3.org/2002/12/rdf-identifiers/
|>  >which seems consistent and I haven't finished thinking
|>  >about - there are things I like about it and things I don't.
|>  >But it does address all the questions, I think.
|>
|> FWIW, I think Sandro's proposal is consistent with the
|> current state of RDF
|> specification, and other views of URIs that have been expressed here,
|> except maybe the view that http: URIs (without fragments)
|> should always
|> denote documents (I hope I don't misinterpret).  My point of
|> divergence
|> with that proposal is the suggestion it should be part of the
|> RDF core,
|> because I don't see the necessity for it to be there.
|>
|> The formal semantics for RDF does tell us one thing, though:
|> in a given
|> interpretation of an RDF graph (document, or collection of documents
|> considered together), a given URI must always denote the same single
|> thing.  So we can't have a graph in which a URI sometimes
|> denotes a car and
|> elsewhere simultaneously denotes a picture.
|>
|> #g
|>
|>
|> -------------------
|> Graham Klyne
|> <GK@NineByNine.org>
|>
|> --
|> --- peterd
|> Sr Security Architect
|> Neustar, Inc.		smtp:   peter.davis@neustar.biz
|> (571) 434 5516		jabber:
|> peter.davis@checkov.neustarlab.biz
|>
|> <Quote type="random">
|> The pursuit of perfection often impedes improvement.
|> <Author>George F. Will</Author>
|> </Quote>
|>
|> PGP Fingerprint:
|> 8994 8774 B682 3A04 B304  C4A2 D9DD 7E5B 8AAC 2D00
|>