thank your for the interesting links. I will have a look at them and
perhaps come back to it in the next days.
>What exactly are you planning?
I developed a paradigm for what I call "persistent linking". The basic
idea is that in order to resolve a link one does not directly access a web
server, but first queries an electronic equivalent for a library catalog or
a bibliography to find out where to look for a certain piece of text. A
similar strategy may be used to access related information, such as
different editions of a work, synoptical passages, commentaries on a
I first tried out this idea by programming an application for a local
system where the catalog is on the user's hard disk. You may find this
application at "http://www.philo.de/ape/". (Since my main guinea pigs are
copyrighted texts from the Wittgenstein Nachlass there are currently not
many primary texts available for download to experiment with, only a short
Currently the catalog implementation is very simple: Each item is
identified internally by means of an URN (a subset of an URI) and presented
on screen by a human-readable short label. So the natural next step is to
relate the URN with all kinds of bibliographic meta-data. Internally this
should be done by a mixture of XML and RDF N3-Triples. So I was looking
for some examples I can follow and experimented a bit with Dublin Core but
concluded that it is too under-complex. MODS comes nearest to my
requirements, since it allows to encode most of the metadata I want to keep.
However, while a MODS record is gathering a lot of information directly in
one record, much of this should be stored separately in the catalog of my
application. For example the meta-data for a journal article should be
stored separately from the meta-data of the journal issue it appeared in,
and be linked by an intermediate information object that represents the
"appearance" relation. If later the article reappears in another
publication a new additional "appearance" relation is added to the catalog
pointing to this other publication.
Another problem is that some features of MODS seem to be too sophisticated
for my target audience of humanities scholars. An example is the nonSort
element in the titleInfo. I would prefer here to encode the whole title in
one element and use another (repeatable) element to include sorting hints:
<title>The Na´vetÚ of Louis ⅩⅥ</title>
<sortkey type='full'>The Naivete of Louis XVI</sortkey>
<sortkey type='skipping'>Naivete of Louis XVI</sortkey>
I do not advocate here to include this notion into MODS, because it would
break its design principle to be a derivative of MARC. This notion is only
an example for a modification I am intending for my application.