Copyright held by
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Further details of licences are available from our
Licences page. For more
information, contact the project director,
Born digital.
Most MoEML documents, or significant fragments with mol:
prefix and accessed through the web application
with their id + .xml
.
The molagas prefix points to the shape representation of a location on MoEML’s OpenLayers3-based rendering of the Agas Map.
Links to page-images in the Chadwyck-Healey
Links to page-images in the
The mdt (MoEML Document Type) prefix used on
The mdtlist (MoEML Document Type listing) prefix used in linking attributes points to a listings page constructed from a category in the central MDT taxonomy in the includes file. There are two variants, one with the plain _subcategories
, meaning all subcategories of the category.
The molgls (MoEML gloss) prefix used on
This molvariant prefix is used on
This molajax prefix is used on
The molstow prefix is used on
The molshows prefix is used on
The sb prefix is used on
Our editorial and encoding practices are documented in detail in the Praxis section of our website.
MoEML aspires to be a persistent Linked Open Data resource which participates
in the broader scholarly effort to identify and describe historical and contemporary
entities of all kinds—people, places, bibliographical items, and so on. For that
reason, each of the entities we identify in our data has a unique id which results
in the creation of a unique page at a stable URL. So Abchurch Lane, for instance, has
the
If the universe of Linked Open Data is to function effectively, such identifiers and URLs must be persistent over the long term. That means that when we first publish a document for a particular entity, we incur an obligation to maintain that document in perpetuity, because other resources must be able to link to it with confidence that it will not disappear.
This obligation is sometimes in conflict with our drive to constantly improve the scholarly focus and quality of our work. We may publish a page on an individual who later proves not to have existed at all, or to be the same person as another individual who has a different id in our system. We may incorporate a site in our collection which later turns out to be located outside the geographical boundaries which circumscribe our project. What do we do in these cases?
One answer to this question is that we no longer remove old editions of MoEML from
the Web; instead, we have a current version which is always at https://mapoflondon.uvic.ca
,
and specific editions which are housed at URLs incorporating their edition number,
such as https://mapoflondon.uvic.ca/edition/6.4/
. However, this is clearly
not sufficient, because despite our citation popups which recommend citing a specific
edition rather than the generic URL, most links and pointers to our work will naturally
point to the generic URL.
For this reason, we have implemented a system of redirects which ensures that when
an entity is retired from the project or merged with another existing entity, its URL
does not simply return a
Before a redirect can be made, someone must follow the following process:
A redirect is a simple instruction in a file called redirects.xml
, which
at the time of writing is located at [svn repo]/db/redirects/redirects.xml
.
Regular research assistants do not normally have permission to commit changes to this file, so
before you try to edit it, check with the project leaders to make sure you are
allowed to make changes to it.
If your normal working method involves checking out the entire MoEML repository
(which is very large), you will be able to locate the file easily. However, if your
normal practice is to check out only the data
folder, you will not
have the file on your computer to edit. In this case, rather than checking out the whole
repository just to access this one file, you can check out only the folder containing
it, outside your regular repository checkout, and edit and commit it there. For example,
if your home directory has a data
folder which contains the MoEML data,
you could do this at the command line:
redirects
with the file
redirects.xml
inside it. You can open this file in Oxygen to edit it.
You’ll see that this file consists of a long list of
mol:COUN2
and mol:SENT1
are both going away). The mol:COUN2
, the redirect points to a page which explains
that the item is rescinded, and gives some generic reasons why we
might rescind an item. In the second case, mol:SENT1
will be redirected to mol:STAU1
. mol:SENT1
was mol:STAU1
is
When an id is redirected, it is not sufficient simply to create
the redirect. Every instance of a link to that id in the whole collection
must be dealt with. When an id is being redirected to another id, this is
simple: just find all instances of links to (for example) SENT1
and replace them with links to STAU1
. In the other case,
though, where an id is being removed from the project, any links to it
must be examined to see whether there is perhaps some other entity to
which they might be linked; if not, then the link itself should be removed,
leaving plain text in place.
If you have been editing in a full checkout of the MoEML repository, you can just commit your changes as you normally would, making sure that you commit at a level which includes both the data files and the redirects file that you have edited.
If you’re working with a separate checkout of the redirects file,
you’ll need to make two commits, one from the redirects
folder, and one from the folder where data
is checked
out.