I had a look at your interesting pages. First of all thank-you for
dedicating some of your time to sum up the various approaches and the
practices related to different standards. Secondly, I would like to admit
that at the moment I am observing P5 rather than using it, so I apologise in
advance if some of my notes may reveal any applicative ignorance.
- first of all, it seems to me that the SVG structure of <svg:g> is much
more modular that the TEI <figure>.
Indeed, it is true that the figure element in P5 can contain multiple
graphical references, however its descriptive child elements (e.g. <head>
and <figDesc>) are related to the group (figure) rather than to the single
<graphic> elements. Am I right?
In SVG instead, each graphics element (not just the container) can include
further specifications of its 'fragmentary' content. I think this feature
should be kept whatever solution is chosen.
- you ask whether the SVG attributes "x" and "y" are necessary. I believe
they are, if we want to provide references to sections of images maintaining
the physical relationship with the overall image. I am not sure which will
be the best way to do this, but for sure TEI needs to support this. In terms
of implementation, a centralised way to record this information (an external
file, a catalogue or a repository of images) is the best solution. Indeed,
coordinates as well as dimensions have the limit of referring to a specific
reproduction and need to be adapted or converted if multiple visualisations
are provided or updated, but at the moment I don't think there is a way
around it (any imaging expert to deny this?)
- If the idea is to support text encoding for resources where images play an
important role, I would be tempted to keep attributes for specifying type of
images (I am referring here to your thought about the <svg:title> without
"type" attribute). However, an approach as the one of Image Markup Tool,
where an annotation in TEI XML is always associated to an SVG element, shows
a way around it. So, for instance if I want to identify all the stitches in
a manuscript, I can do it in the mark-up of the annotation rather then
within the svg elements. Does this mean that the text remain the dominant
representation? I suppose so.
- you point out the visualisation problem in your conclusions. I think this
is a fundamental issue. Is it useful to create the most complex - more or
less elegant - codes that can speculate on all the possible theoretical
cross-references between sections of texts and sections of images without
actually showing them? I suppose it may be a useful approach to set up a
model, to discuss options of mark-up, but what we need in our projects are
concrete publications and presentational tools.
I guess I have raised problems and increased confusion rather the proposing
solutions, but I hope you can find some useful crumbs here.
All the best,
From: TEI (Text Encoding Initiative) public discussion list
[mailto:[log in to unmask]] On Behalf Of Dot Porter
Sent: 08 June 2006 19:30
To: [log in to unmask]
Subject: Image Encoding
At the TEI Council meeting last month, Conal Tuohy and I volunteered
to do some footwork to look at how the TEI might improve its support
for projects that include digital images. To this end, we've posted
some material to the wiki and we invite everyone on the list to take a
look, make suggestions (on the list, or through editing the wiki), and
to think about how you would like to use the TEI to support your
projects that include digital images - and, of course, share your
thoughts with the rest of us.
Here is a page that compiles some existing approaches to image
encoding: those from the current TEI P5 Guidelines, the Draft
Recommendations for TEI Digital Facsimiles (from 2001), the methods
used by the EPPT and the UVic Image Markup Tool, and an untested
system using METS to link TEI and images. If your current practice
doesn't appear on this list, please feel free to add it.
The major concern for the last three approaches is how to link a
section of an image to a section of text, the coordinates of a
bounding box to a given TEI element. The main issues here are
1) where to store the coordinates
2) what syntax to use for the coordinates
3) how to link the image coordinates (and the identity of the image
file itself) to the TEI element
Since there is already a standard for describing image information in
XML, Scalable Vector Graphics (SVG), I've also compiled a page looking
at ways to use SVG in TEI to help provide support for image encoding.
This page also looks at ways that TEI repeats functionality in SVG and
suggests ways that TEI might incorporate elements from the SVG
namespace rather than using different elements in the TEI namespace.
Both of these pages are still very much in draft form, but I hope that
you find them interesting and that they are a good starting point for
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY 40506
[log in to unmask] 859-257-9549