I agree with you and Dot and am in favour of @facs for at least two reasons:
- the guidelines do not specify the use of @facs only for transcriptions
as you point out and this was rather deliberate since, as Dot says, we
wanted to allow the correspondence between images and text for other
cases too (e.g. palaeographic commentary);
- I have used IMT with various groups of students now and its simplicity
is stunning, very much appreciated by beginners and worth keeping (you
can always costumise it if you want!), so although we could
differentiate between different types of annotations, @facs seems the
best candidate for expressing a straight forward -not further specified-
All the best,
Dot Porter wrote:
> Hi Martin,
> I think you should use @facs. The introduction to 11.1 Digital
> Facsimiles says about a digital facsimile, "Such a collection may form
> part of any kind of document, for example a commentary of a
> codicological or paeleographic nature, where there is a need to align
> explanatory text with image data." This is pretty clearly what you
> want to do (align explanatory text - annotations - with image), and
> since @facs is the linking attribute defined for digital facsimiles,
> it's what should be used. My understanding is that @facs is a general
> attribute for linking "text" to "image", and I don't agree that we
> should limit that linking to transcription-image of text only.
> On Dec 19, 2007 12:15 PM, Martin Holmes <[log in to unmask]> wrote:
>> Hi folks,
>> 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" />
>> <div has-something-to-do-with="zone_01">
>> 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
>> it was.
>> 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,
>> Martin Holmes
>> University of Victoria Humanities Computing and Media Centre
>> ([log in to unmask])
>> Half-Baked Software, Inc.
>> ([log in to unmask])
>> [log in to unmask]
Dr Arianna Ciula
Centre for Computing in the Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL (UK)
Tel: +44 (0)20 78481945