>If I remember rightly, the TEI text that Martin's tool creates is not
>(necessarily) the transcription of an old text. It might as well be a
>new, editorial text about an image fragment. The editor, using the
>tool, creates a new text. It would seem to me therefore that the
>creation element is appropriate.
That's correct; these are new "texts", formed by associating editorial
information (annotations) with an image file. The images are not
(necessarily, or even usually) of text. (This is very different from the
EPT, which really specializes in images which are of text, and their
transcription.) This is why I initially liked the creation element. It's
also unlikely the tool would load general-purpose TEI documents not
created with it (although it will load and save into a DocBook format as
well as TEI+SVG). It could, however, load files initially created with
it, then edited in another application (such as oXygen) as long as the
key parts of its structure relating to the image and annotations were
Lou Burnard wrote:
> Dot's example suggests that we need some special tags for naming
> software products e.g. <productName>, <productVersion> etc. which can
> appear wherever <name> is permitted. Wouldn't you want the identifier
> for the version within the name, rather than as a sibling of it though?
It might be best to begin by setting out the array of information we may
want to record with these tags. I've already listed three items:
appName (human-usable application title)
appURI (i.e. where you could go to get the application, or info about it)
appVersion (conventional dot-separated Major, Minor, Release and Build
I think this may also be very useful:
This would be an identifier for the application which conforms to xml:id
constraints. Such ids are used by application developers, for example to
create a mutex when an application is running in Windows, so that an
installer or uninstaller can check to see whether the application is
already running before attempting to install it or uninstall it.
We can imagine lots of others, relating to licensing (GPL, Moz 1.1,
etc.), registered user, programmer or publisher, but these are less
important and more difficult to constrain to a fixed format.
I prefer "app" to "product" as a prefix; "product" has a rather nasty
marketing-speak flavour about it to me, although that's a personal thing.
There is an analogue for all this in the Windows file versioning
information system (and presumably on other platforms too). Any Windows
executable can contain a data structure which encodes a range of
name-value pairs, many of which are formally documented and expected
(major version, minor version, build, release, etc.) and some of which
are conventional, but it also allows you to add your own name-value
pairs and use standard API calls to retrieve them. If we're considering
creating a new structure or set of tags, I think it would be a good idea
to follow a similar model, with some items we'd expect the application
to add to the file, but with the flexibility for other information to be
encoded in a standard way. Something like this is what I imagine:
<appIdent key="appName">Image Markup Tool</ident>
<appIdent key="userDefined" userKey="licence">Mozilla Public Licence
<date value="2006-05-25T11:03:55">Last save: 2006-05-25 at
With a system like this, getting all the available info about an
application is simply a question of iterating through the appIdent tags.
specific info can be retrieved using the key attribute (or whatever
would be a better name for it). The key attribute could be constrained
to an enumeration which also includes "userDefined", and that could be
used in combination with an unconstrained userKey attribute to add any
info the developer thinks is required.
The date tag is useful in this scenario:
We can envisage multiple applications working on a file in sequence, and
it would be politic not to destroy the creatorApp information about
previous applications. For instance, imagine that someone creates a
really powerful and intuitive tool for building teiHeaders, and that's
all it does. You might mark up an image using the Image Markup Tool
(which lets you edit the teiHeader as text, but doesn't help you with
it), and then use the teiHeader tool to add an elaborate header. You
could then edit the file again in the Image Markup Tool (which wouldn't
damage or change any elements of the teiHeader other than those which
directly concern it). It would be important to know which of these
applications was used to edit the file, and when. So each tool, assuming
they're both using this proposed versioning system, would be able to
identify its own creatorApp tag (using the appId) and modify that every
time it edited the file, while leaving the other application's
creatorApp tag alone.
Does this make sense?
I really don't want to customize my schemas to add support for this
information; it really is useless if it can't be found in a predictable
location in a reliable format, because the whole idea is that it be read
and written automatically by authoring programs.
> Dot Porter wrote:
>> Peter, you're correct - the image descriptions that Martin's tool
>> creates could be either completely new texts, or transcripts of
>> existing texts. Does it make sense to use <respStmt> to note the
>> software and <creation> to note the "newness" of the descriptions? I'm
>> just not comfortable using <creation> to note the software.
>> <resp>encoded using</resp>
>> <name>Image Markup Tool</name>
>> <resp>encoded by</resp>
>> <name>Dot Porter</name>
>> and, if the image descriptions are new:
>> Image descriptions by Dot Porter.
>> On 5/25/06, Peter Boot <[log in to unmask]> wrote:
>>> Dot Porter wrote:
>>>> Martin, I agree with Lou; from the description in the guidelines it
>>>> looks like <creation> is specifically to describe the source text.
>>> If I remember rightly, the TEI text that Martin's tool creates is not
>>> (necessarily) the transcription of an old text. It might as well be a
>>> new, editorial text about an image fragment. The editor, using the tool,
>>> creates a new text. It would seem to me therefore that the creation
>>> element is appropriate.
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]