Some additions after your comments and after Sebastian's clarification:
>Yes, if I understand you here (and your clarification under separate
>cover). But I don't know if I agree that <svg:g> improves on this.
- in SVG you are allowed to add descriptions and titles to any graphics
element (e.g. to <rect>).
Now, if the latter structure is valid in P5, as Sebastian confirmed,
<head>My entire image</head>
we can use the <figure> element at different levels in the hierarchy both to
mark-up an overall image and its fragments or sections. So there is not
complete symmetry between the TEI <graphic> and the SVG graphics elements,
but it doesn't seem we are loosing any possibility of expression here (at
least as far as my needs of encoding are concerned).
As it is probably made clear by my banal example, what I was thinking of is
the possibility to mark-up a page image of a manuscript and all its relevant
semantic sections (where "semantic" here means generally "with meaning", so
a component of the layout, if considered relevant for the encoding, can be
marked-up as well as a damaged/not readable area).
>I'm just saying that
>svg:title would only be used in reference to images; <svg:title
>type="image"> is a bit redundant.
- got you now, sorry
If I have to express my opinion, I am very much in favour of trying to
"modulate" SVG, as you say on the wiki, rather than making a mirror of its
functionalities. It's a standard and works well.
All the best,
From: TEI (Text Encoding Initiative) public discussion list
[mailto:[log in to unmask]] On Behalf Of Dot Porter
Sent: 16 June 2006 14:27
To: [log in to unmask]
Subject: Re: Image Encoding
Hi Arianna, (and sorry to all in advance for my too-long message)
Thanks for your thoughtful comments. Mine are interspersed below...
On 6/15/06, Arianna Ciula <[log in to unmask]> wrote:
> Some thoughts:
> - 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?
Yes, if I understand you here (and your clarification under separate
cover). But I don't know if I agree that <svg:g> improves on this.
> 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.
I think <svg:g> and <svg:figure> both have this problem. So:
<graphic width="4" height="2" url="fig1.png" mimeType="image/png"/>
<head type="image title">Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
is equivalent to
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</svg:desc>
Though <figure> can include more than one <graphic>, but as you point
out the <head> and <figDesc> describe the whole figure (and all child
<graphic>s). To describe multiple <graphic>s (thinking of them as part
of a whole) you would need now to have multiple <figure>s. Arianna, is
this your issue? I think SVG is the same - if we place another
<svg:image> in that second example [I'm not sure if that is valid]
then the following svg:title and svg:desc would still describe both
images. What if there were a way to nest multiple <graphic>s with
their own descriptive information within <figure>? Can you think of an
example of where this would be especially useful?
> - 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
> the physical relationship with the overall image.
Another option would be to use @mets:coords
The differences are that 1) @mets:coords holds all coordinates in a
single attribute value and 2) @mets:coords can describe circles and
polygons with straight edges, while SVG x,y etc. coordinates allow for
more advanced shapes with, for example, rounded corners.
> I am not sure which will
> be the best way to do this, but for sure TEI needs to support this. In
> of implementation, a centralised way to record this information (an
> 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
> reproduction and need to be adapted or converted if multiple
> are provided or updated, but at the moment I don't think there is a way
> around it (any imaging expert to deny this?)
Conal and I have been talking about mapping coordinates between
different images of the same physical object, but haven't come up with
any good ideas. Honestly it's beyond my technical abilities, but it's
something we need. Best I think if we can find something (maybe the
SVG coordinate transformation http://www.w3.org/TR/SVG11/coords.html -
the EPPT also has an overlay function that maps coordinates between
images) rather than try to invent something new for the TEI.
> - If the idea is to support text encoding for resources where images play
> important role, I would be tempted to keep attributes for specifying type
> images (I am referring here to your thought about the <svg:title> without
> "type" attribute).
Well, in this instance @type would refer to the type of svg:title, not
the type of image. In TEI, we'd have <head type="image"> (or "figure")
to differentiate it from other types of head elements in the TEI
document (chapter headings, for example). I'm just saying that
svg:title would only be used in reference to images; <svg:title
type="image"> is a bit redundant.
> However, an approach as the one of Image Markup Tool,
> where an annotation in TEI XML is always associated to an SVG element,
> a way around it. So, for instance if I want to identify all the stitches
> 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.
So, for example, describing a manuscript using msDescription,
describing (and perhaps listing the occurrences of) stitches - or
rubrics, marginal guide letters, or what have you - and then somehow
linking the description (or the individual occurrences) to those areas
on the images that correspond to the descriptions? (I really like
this) So the text is the dominant representation, but always refers to
the images as a reference.
I'm approaching this from a slightly different angle. What I would
like to do is link my source images (in my case medieval manuscripts,
but the idea is applicable to any other primary written source I can
think of) to the TEI encoding of the text. So I'm not really talking
about annotation, describing an image/physical object, but describing
the impact that the physical object has on the text that lives in it.
TEI already does this - I'm thinking of <damage> and <unclear>
especially - but I would like to say "this line of text is damaged,
and here is the area of the image file where you can see it." Hence my
suggestion on the wiki that some coordinate attribute be optional on
the elements described in Ch. 18 Transcription of Primary Sources. The
EPPT does this, using a catalog of image files and an attribute to
hold coordinates for bounding boxes within the elements themselves;
another approach would be to instead link elements to bits of SVG
identifying image files and coordinates. I don't know which one is
preferable, but I do think TEI should include one of these (or both,
or something else I haven't thought of) in the Guidelines.
> - you point out the visualisation problem in your conclusions. I think
> 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.
Oh, yes, yes. Yes. The only two image editing/presentation tools that
I know of are the EPPT and IMT, and they have different aims and use
very different approaches to coordinates. There are also XML/TEI
editors (oXygen) and SVG editors (Amaya - has anyone on the list used
this tool?) but without guidance it's difficult to figure out how to
use them together.
> I guess I have raised problems and increased confusion rather the
> solutions, but I hope you can find some useful crumbs here.
> All the best,
> -----Original Message-----
> 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
> Hello List,
> 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
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