I'm rewriting the Image Markup Tool so that it uses the new <facsimile>,
<surface> and <zone> elements instead of SVG, giving it a "pure" TEI
file format in one namespace. Quite a few people have asked for this,
and it seemed a great idea when I started.
I've been getting help and suggestions from Conal Tuohy about the best
way to go about this, and we're largely agreed on most things, but there
is one issue that still isn't clear, so I'd like to raise it here.
The situation is that I need to link generic blocks of TEI code (<div>
elements) to <zone> elements, using an attribute:
<zone xml:id="zone_01" ulx="5" uly="20" lrx="100" lry="180" />
The issue is what should be used for the "something-to-do-with"
attribute. The primary problem is that the application is a general tool
which cannot discover or dictate the nature of the relationship between
the <zone> and the <div>. Sometimes the <div> might contain a
transcription of text in the <zone>; sometimes it might be a description
of an object; sometimes it could be editorial analysis, or "annotation"
(whatever that is), or any number of other types of relationship. The
IMT is written for novice users, and I don't believe it would be
effective, helpful or appropriate to menace them with interrogation
about the precise nature of the relationship between the text they're
associating with the zone; nor do I think it would be easy to predict
all possible types of association. Finally, IMT is used quite a lot by
people who don't care about TEI at all; they just want to get the "Web
View" HTML output from it, so they have no interest in being explicit
about the nature of the relationship between their "annotation" and the
square bit of the image it's associated with.
So I need a single attribute that can be used in all cases, whatever the
nature of the relationship between the <div> and the <zone>. The
candidates that have emerged from the discussion so far are these:
I believe this is intended specifically for linking where the
relationship involves some linguistic or similar analysis; in other
words, I think this is too specific for a general case.
I would have thought from the guidelines that this is precisely the
general attribute I need, but in a recent post Lou said this:
"all the examples of suggested uses for @corresp show it
being used for various kinds of linguistic alignment!"
which carries the suggestion that these are the appropriate uses for it,
and that perhaps it isn't the general-purpose attribute I once thought
This is my favourite, because it comes with the <facsimile> family, and
the one thing I do know is that I'm linking to a <zone>. The guidelines
say that @facs is used on "elements which can be associated with an
image or a surface within a <facsimile> element". That seems fairly open
to me, and I hope it's the case.
However, Con's position is different (and he was the prime mover behind
<facsimile>). He maintains that its only appropriate use is to link a
_transcription_ to a <facsimile>, <surface> or <zone>; other types of
relationship are not appropriate. In other words, it's not suitable for
the general case I'm dealing with. I don't think the guidelines support
this; @facs is global, so I can add @facs to <publicationStmt>, or
<fileDesc>, or <keywords>, or <tagsDecl> -- and they're pretty unlikely
to contain transcription. The guidelines further say:
"This attribute may be used to associate any element in a transcribed
text with an image of it, by means of the usual URI pointing mechanism."
where, to me, "may" suggests this is _one_ acceptable use of @facs, not
the only one. I'm happy to be told I'm wrong here, but if so, I think
the guidelines do need to be more explicit about this.
@n is often used as a fallback where you need to store
something-or-other and you don't want to be specific or restrictive
about what it is. But that in itself is an argument against it; I'd like
my attribute to be restricted to well-formed URIs. Also, the guidelines say:
"The n attribute may be used to specify the numbering of chapters,
sections, list items, etc.; it may also be used in the specification of
a standard reference system for the text."
I'm not actually doing any of those things.
So what do you think?
All help appreciated,
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]