[topicmapmail] Merge Classification into TopicMap's knowledge Space-Mao Jun from LAS
maojun
maoj@mail.las.ac.cn
Mon, 09 Sep 2002 14:04:10 +0800
This is a multi-part message in MIME format.
--Boundary_(ID_GwPkgH/0fmF7NxGU+TA7rQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
I tend to reform the library's classification with TopicMap's concept and methode,here is the reason:
1.Clssification system should be dynamic instead of static:
Traditional Classification system was used to classify book,journal etc. print document and place them on the properiate shelf, the library reasearcher edit and maintain the classification table, We need .
This enviroment has changed,we need to identify internet resource or "objects" available on the net,The rapidly changed information resource on type and location demand a dynamic,user-oriented,self-developing Classification system.
The Classifcation should be used in the use.
If you have any question,Do not hesitate to let me know.
Yours,
Mao Jun
Academy of Chinese Sciences Digital Library(CSDL)
mail: maoj@mail.las.ac.cn
http://www.las.ac.cn/csdl
phone:+86-010-82628382
fax:+86-010-82628382
--Boundary_(ID_GwPkgH/0fmF7NxGU+TA7rQ)
Content-type: message/rfc822
Date: Sun, 08 Sep 2002 01:01:01 +0800
From: topicmapmail-request@infoloom.com
Subject: topicmapmail digest, Vol 1 #768 - 6 msgs
Sender: topicmapmail-admin@infoloom.com
To: topicmapmail@infoloom.com
Reply-to: topicmapmail@infoloom.com
Message-id: <20020907170101.4B4C514C84B@amati.petesbox.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Mailman v2.0.5
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-BeenThere: topicmapmail@infoloom.com
X-Mailman-Version: 2.0.5
List-Subscribe: <http://www.infoloom.com/mailman/listinfo/topicmapmail>,
<mailto:topicmapmail-request@infoloom.com?subject=subscribe>
List-Unsubscribe: <http://www.infoloom.com/mailman/listinfo/topicmapmail>,
<mailto:topicmapmail-request@infoloom.com?subject=unsubscribe>
List-Help: <mailto:topicmapmail-request@infoloom.com?subject=help>
Send topicmapmail mailing list submissions to
topicmapmail@infoloom.com
To subscribe or unsubscribe via the World Wide Web, visit
http://www.infoloom.com/mailman/listinfo/topicmapmail
or, via email, send a message with subject or body 'help' to
topicmapmail-request@infoloom.com
You can reach the person managing the list at
topicmapmail-admin@infoloom.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of topicmapmail digest..."
Today's Topics:
1. Document Object Identifiers/CrossRef (Suellen Stringer-Hye)
2. Astronomical use of Topic Maps (Bernard Vatant)
3. RE: Re: Document Object Identifiers/CrossRef (Daniel Rivers-Moore)
4. Re: Re: Document Object Identifiers/CrossRef (W. Eliot Kimber)
5. Re: Re: Document Object Identifiers/CrossRef (Anthony B. Coates)
6. Re: Re: Document Object Identifiers/CrossRef (Anthony B. Coates)
--__--__--
Message: 1
From: "Suellen Stringer-Hye" <Stringers@LIBRARY.Vanderbilt.edu>
Organization: Vanderbilt University
To: topicmapmail@infoloom.com
Date: Fri, 6 Sep 2002 14:28:37 -0500
Subject: [topicmapmail] Document Object Identifiers/CrossRef
Here is the abstract and citation from an article describing how libraries are
currently using both DOIs and SFX (open URL I mentioned in a previous
post). Let me know if you'd like a copy of the article and I'll send it to you.
---Suellen
Title: CrossRef and SFX: complementary linking services for libraries
Author(s): Jenny Walker Journal: New Library World Year: 2002 Volume:
103 Number: 3 Page: p83 -- p89 DOI: 10.1108/03074800210422296
Publisher: Emerald Abstract: With the increase in the use of electronic
information services in libraries, and in particular with the dramatic increase
in the use of electronic journals, there is an urgent need by libraries for
solutions that link the disparate information resources in a meaningful way
for the end user and that optimize the use of these resources. Such linking
solutions are now available for libraries, supported and assisted by the
emergence of new standards such as the OpenURL and the Digital Object
Identifier (DOI). Linking solutions built around these standards include SFX
and CrossRef. Demonstrates how these different solutions, and the
underlying standards, interact to meet library needs.
Suellen Stringer-Hye
Jean and Alexander Heard Library
Vanderbilt University
stringers@library.vanderbilt.edu
--__--__--
Message: 2
From: "Bernard Vatant" <bernard.vatant@mondeca.com>
To: "TopicMapMail" <topicmapmail@infoloom.com>
Cc: <aam@astro.caltech.edu>
Date: Sat, 7 Sep 2002 11:28:39 +0200
Subject: [topicmapmail] Astronomical use of Topic Maps
Gathering topic maps use cases from Google to feed
http://dmoz.org/Computers/Artificial_Intelligence/Knowledge_Representation/Topic_Maps/Exam
ples_and_Use_Cases/
(sorry for the long broken URL ...)
I stumbled on this very interesting one I did not know of:
http://www.astro.caltech.edu/~aam/science/topicmaps/
It's an application to astronomical data base by a CalTech team, called "Topic Maps for
the Virtual Observatory". What is interesting is a tool allowing users to generate
automatically a Topic Map from data tables of their choice.
Comments welcome, to this forum and to the author of the project in cc.
Bernard
-------------------------------------------------------------------
Bernard Vatant
Consultant - Mondeca
www.mondeca.com
Chair - OASIS TM PubSubj Technical Committee
www.oasis-open.org/committees/tm-pubsubj/
-------------------------------------------------------------------
--__--__--
Message: 3
Subject: RE: [topicmapmail] Re: Document Object Identifiers/CrossRef
Date: Sat, 7 Sep 2002 13:30:07 +0100
From: "Daniel Rivers-Moore" <Daniel.Rivers-Moore@rivcom.com>
To: "Anthony B. Coates" <abcoates@TheOffice.net>,
"topicmapmail" <topicmapmail@infoloom.com>
Thanks Tony. That makes sense (though it's not altogether good news).
Does anyone on this list have a sense of whether there is a strong lobby
to get W3C to open its attitude in this regard? I am RivCom's W3C rep,
but don't have the bandwidth to follow all the issues, so have not
caught up on this one for some time. Certainly in the old days there was
a kind of religious war over whether the URN had any intrinsic value
over the URL. Not whether URN was 'better' or 'worse' than URL, but on
whether 'URL alone' was better than 'URL and URN, each used
appropriately'.
I get the feeling that the "URL rules all and nothing else is needed"
position has somewhat lost its credibility (am I right?). But Tony
asserts below that the W3C still "does not seem keen on widespread use
of URNs". Why might that be? Is there a body of opinion or influence
within or outside W3C that might move this debate forward in useful
directions?
[BTW, if someone thinks this is getting too far off topic for this list,
please shout. I myself think that it is not at all off topic, because
Topic Map PSIs are certainly intended to provide the basis for a
persistent reference mechanism for topics, and the choice of protocol
for expressing them - URL, URN, DOI, or other - is of considerable
interest, IMHO)
Regards
Daniel
-----Original Message-----
From: Anthony B. Coates [mailto:abcoates@TheOffice.net]
Sent: 06 September 2002 17:30
To: topicmapmail
Subject: Re: [topicmapmail] Re: Document Object Identifiers/CrossRef
** Reply to message from "Daniel Rivers-Moore"
<Daniel.Rivers-Moore@rivcom.com>
on Fri, 6 Sep 2002 15:08:18 +0100
Dear Daniel,
> Out of curiosity back to you, Tony, does IETF's DDDS URN-URL
resolution
> simply define a way of doing the resolution in principle, or are there
> also working software and installed service providers?
I'm not aware of any widespread use yet, but DDDS is basically an
enhancement
to DNS that is designed to be as easy as possible to implement & deploy.
One
issue is that the W3C does not seem keen on widespread use of URNs.
They would
prefer people to provide URLs instead, and just manage them
persistently. The
lack of W3C support certainly makes life tougher for DDDS.
Cheers,
Tony.
=3D=3D=3D=3D
Anthony B. Coates, Information & Software Architect
mailto:abcoates@TheOffice.net
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/
_______________________________________________
topicmapmail mailing list
topicmapmail@infoloom.com
http://www.infoloom.com/mailman/listinfo/topicmapmail
--__--__--
Message: 4
Date: Sat, 07 Sep 2002 08:11:26 -0500
From: "W. Eliot Kimber" <eliot@isogen.com>
Reply-To: eliot@isogen.com
Organization: ISOGEN International
To: topicmapmail <topicmapmail@infoloom.com>
Subject: Re: [topicmapmail] Re: Document Object Identifiers/CrossRef
Daniel Rivers-Moore wrote:
> Does anyone on this list have a sense of whether there is a strong lobby
> to get W3C to open its attitude in this regard? I am RivCom's W3C rep,
> but don't have the bandwidth to follow all the issues, so have not
> caught up on this one for some time. Certainly in the old days there was
> a kind of religious war over whether the URN had any intrinsic value
> over the URL. Not whether URN was 'better' or 'worse' than URL, but on
> whether 'URL alone' was better than 'URL and URN, each used
> appropriately'.
The last time I discussed this with Dan C. (about a year ago, I think)
he re-iterated Tim B-L's argument made in a paper on the W3C site that
there's no useful difference between URLs and URNs--they're both just
magic strings. One key aspect of the argument was/is that the
indirection provided by URNs can be provided today by any Web server and
that, in any case, it is always the resposibility of the manager of the
resource to maintain the ability to resolve it, which either means
maintaining something like the mappings provided for by the DOI/CrossRef
infrastructure and PURL systems or maintaining a redirect mapping on
your local server.
I keep going back and forth in my own mind on this issue--I was raised
on public IDs and believed they were the answer for a long time. Then I
helped make XML and decided that public IDs were bogus--that system IDs,
especially in the context of a Web-type resolution infrastructure, were
all you needed (by the "do it on the server" argument above).
But in thinking about it more since then, I think that, while Tim is
technically correct, I think that the real difference between URNs and
URLs (that is, between names and locators) is one of expectation: if you
see a URN (a name) you expect two things: that you will have to go
through some sort of indirection mechanism to resolve it and that it
will probably resolve to the "correct" thing whenever you do choose to
resolve it, whereas with a URL you expect that you can resolve it
directly but you also aren't surprised if it fails to resolve because
"it's just a locator".
[Side note: I think what's bogus about public IDs is not that SGML and
XML provide both a name and a locator but that you can use *both* in a
single reference--that's the bogus part. There should be a single
external reference, where the syntax of the reference lets you
distinguish names from locators--that is, URIs got it right.]
>From the standpoint of publishers, I think there is value in having a
name-based addressing mechanism that matches both the requirement and
expectation that "persistent" names are being used--if I'm publishing a
scholarly work that I want to be findable and usable (through any
references it makes) 5, 10, or 100 years out, I want some assurance that
the names I'm using will resolve appropriately in the future. If this
resolution is being managed by a disinterested 3rd party (e.g.,
CrossRef) I'll probably have greater confidence than if it's being
managed by the enterprise that happens to be serving the named things at
the moment (if for no other reason than that my experience with the Web
suggests that Web sites tend to be poorly managed over time, eroding my
confidence in Web sites generally).
What I think this comes down to is that by exposing and centralizing the
indirection mechanism (CrossRef instead of a bunch of redirect tables on
a bunch of Web servers) it provides a single point of contact for both
creating and maintaining the indirections by resource managers and
finding and verifying references by resource users.
I think part of the problem with the URL-only argument is that URLs are
unavoidably bound to particular domain names, which are too bound to
brand identity (even though the URL spec says that URLs are to be
opaque). Thus, the temptation to move resources from one domain name to
another as brands evolve or ownership changes is too great. When a
resource moves from one server to another with a different name it can
be very difficult to find that resource's new location. It's unlikely,
especially when ownership changes, that the old server would be
maintained in order to provide redirections to the new server.
Interestingly, the DOI syntax avoids this problem to some degree by
making the owner identifiers opaque as well--very clever I think, and
possibly key to making DOIs truly persistent. That is, the DOI
recognizes that the "owner" of the name is not necessarily the owner of
the intellectual property named, just the manager of the name itself
(that is, the manager of the name's mapping to addressible resources).
There's no need for brand identification of name managers--that's just
plumbing, after all. (But note that the DOI mechanism can't restrict
what you use for resource identifiers in a DOI, so there's still room
for brand identifiers in DOIs, for example, if you use an existing URL
as the resource ID part of a DOI.)
Therefore, I think that the "do it all with URLs" argument is naive--it
ignores human nature. A centralized indirection mechanism at least
lowers the long-term cost of maintaining the resolvability of names.
Once the setup cost has been spent, there's no reason not to use the
indirection unless the ongoing cost is prohibitive. Ideally this type of
resource would be a public utility as DNS is today.
OK, I've convinced myself that URLs are not enough.
Cheers,
E.
--
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
--__--__--
Message: 5
Date: Sat, 7 Sep 2002 14:15:29 +0100
To: "topicmapmail" <topicmapmail@infoloom.com>
From: "Anthony B. Coates" <abcoates@TheOffice.net>
Reply-To: "Anthony B. Coates" <abcoates@TheOffice.net>
Subject: Re: [topicmapmail] Re: Document Object Identifiers/CrossRef
** Reply to message from "Daniel Rivers-Moore" <Daniel.Rivers-Moore@rivcom.com>
on Sat, 7 Sep 2002 13:30:07 +0100
> I get the feeling that the "URL rules all and nothing else is needed"
> position has somewhat lost its credibility (am I right?). But Tony
> asserts below that the W3C still "does not seem keen on widespread use
> of URNs". Why might that be? Is there a body of opinion or influence
> within or outside W3C that might move this debate forward in useful
> directions?
Personally, I don't think the W3C wants important elements of its
"Web Architecture" to be out of its control, as URNs are. Since you
can always map a URN onto a URL (persistence of the URL
notwithstanding), there is no actual technical need for the W3C to
be inclusive about URNs. It actually only introduces a technical
headache for them.
I think the only thing that would likely change this would be
widespread usage of URNs in spite of their preference.
However, I'm not sure that this is likely to happen, given
the high level of thought leadership that the W3C have
in this area.
Cheers,
Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@TheOffice.net
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/
--__--__--
Message: 6
Date: Sat, 7 Sep 2002 14:22:54 +0100
To: topicmapmail <topicmapmail@infoloom.com>
From: "Anthony B. Coates" <abcoates@TheOffice.net>
Reply-To: "Anthony B. Coates" <abcoates@TheOffice.net>
Subject: Re: [topicmapmail] Re: Document Object Identifiers/CrossRef
** Reply to message from "W. Eliot Kimber" <eliot@isogen.com> on Sat, 07 Sep
2002 08:11:26 -0500
> From the standpoint of publishers, I think there is value in having a
> name-based addressing mechanism that matches both the requirement and
> expectation that "persistent" names are being used--if I'm publishing a
> scholarly work that I want to be findable and usable (through any
> references it makes) 5, 10, or 100 years out, I want some assurance that
> the names I'm using will resolve appropriately in the future.
In the database world, there is this idea of "natural keys" for information.
While you can design a database schema in which every surname has
a matching ID, with all references based on the ID, you can also just use
the surname as a key. That can have some issues when a surname
changes, but the advantage of natural keys is that they are very robust
when it comes to location the information you want. You don't have to worry
about orphaned IDs & such.
There is a sense in which URIs are like IDs. On the Web, the nearest
analogue to natural keys are (i) using a search engine to locate pages,
and (ii) using Dublin Core metadata. It is worth wondering, then, whether
the fragility of URIs is more the fragility of using URIs as the persistent
addressing mechanism, when something based on natural keys would
be better. Just a thought, anyway.
Cheers,
Tony.
====
Anthony B. Coates, Information & Software Architect
mailto:abcoates@TheOffice.net
MDDL Editor (Market Data Definition Language)
http://www.mddl.org/
--__--__--
_______________________________________________
topicmapmail mailing list
topicmapmail@infoloom.com
http://www.infoloom.com/mailman/listinfo/topicmapmail
End of topicmapmail Digest
--Boundary_(ID_GwPkgH/0fmF7NxGU+TA7rQ)--