[sc34wg3] TMQL Tutorial (Preview)
Robert Barta
sc34wg3@isotopicmaps.org
Mon, 16 May 2005 18:58:17 +1000
On Wed, May 11, 2005 at 08:06:39AM +0200, Steve Pepper wrote:
> | Lars and /me have worked on a first tutorial on how TMQL could look
> | like. It is currently staged (inofficially) at
> |
> | http://topicmaps.it.bond.edu.au/docs/39?style=printable
> Under "Identifying Things" you use the URN "urn:x-ASIN:B0006399FS"
> as an example of a subject locator (used as an identifier for the
> album "How to Dismantle an Atomic Bomb").
>
> This does not accord with my view of what a subject locator is. I
> thought there was broad consensus in the community that a subject
> locator is the locator (or address) of a subject; that resolving
> a subject locator returns the subject itself; and that subject
> locators can therefore only be used as identifiers for (network-
> retrievable) information resources.
>
> The current draft of the TMDM is pretty clear on this, at least in
> the glossary (http://www.jtc1sc34.org/repository/0588.pdf):
>
> 3.24 subject locator
> a locator that refers to the information resource that is the
> subject of a topic. The topic thus represents that particular
> information resource; i.e. the information resource is the
> subject of the topic.
>
> 3.8 information resource
> a resource that can be represented as a sequence of bytes, and
> thus could potentially be retrieved over a network
>
> By this definition, the album "How to Dismantle an Atomic Bomb" is
> not an information resource and therefore cannot be identified by
> a subject locator.
Steve,
What you are effectively saying is, that it is not possible -
according to TMDM - to use a URN as a subject locator. If that were
the case, then TMDM should say so.
I wonder, though, why this should not be possible. Both, URNs and URLs
are both locators for information resources. According to
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#URLvsURN
they simply differ in that UR_L_s not only name the resource, but also
additionally provide a network location. One nice effect URNs have though:
The term "Uniform Resource Name" (URN) has been used historically
to refer to both URIs under the "urn" scheme [RFC2141], which are
required to remain globally unique and persistent even when the
resource ceases to exist or becomes unavailable, and to any other URI
with the properties of a name.
So, to keep my topic maps (and my queries) robust against the tides
of change, using
urn:x-ASIN:B0006399FS
seem the better choice compared to, say...
> I suggest your example use a web page about the album instead (e.g.
> http://en.wikipedia.org/wiki/How_to_Dismantle_an_Atomic_Bomb).
...which may (at best) serve as indicator for my subject. How this name
may be resolved to a URL is a local policy.
Now the only discussion point remaining is whether "the album 'How to
Dismantle an Atomic Bomb'" can be regarded as 'information
resource'. But that discussion kept the TAG (web technical
architecture group) busy for weeks.
At least my cat is an 'information resource' which can be easily
proven:
http://james.bond.edu.au/news.mc?id=784
\rho