On Dec 20, 2007 9:35 PM, Conal Tuohy <[log in to unmask]> wrote:
> Afternoon Dot! :-)
And now it's morning again! I really wish we didn't have to deal with
this time difference.
Unfortunately I don't have the time or energy today (the last workday
before a well deserved vacation!) to answer all your points - which
are very good ones. I think we just very basically disagree on how
@facs should be used, and I wish that this issue had come up when
Council was working out the specifics of facsimile. In any case, I
agree with you that the TEI Council needs to revisit the Guidelines
and clarify this soon. And I promise to abide by whatever decision
they make :-0
> > On Dec 20, 2007 6:23 PM, Conal Tuohy <[log in to unmask]> wrote:
> > > But I don't see why the "facsimile system" should be reduced to use only
> > > the @facs attribute and not also the other linking attributes present in
> > > TEI. That seems to me a rather arbitrary limitation.
> > >
> > @facs is defined as "points directly to an image, or to a part of a
> > facsimile element which corresponds with this element." I don't see
> > what is arbitrary about saying that, if you are going to link text (be
> > it transcription or description) to an image, use @facs.
> My view is that @facs should be considered some more specific than just
> a generic pointer which happens to point to a tei:zone (or other
> facsimile element)
> The @facs attribute is a pointer (in common with a large number of other
> attributes in TEI, such as @ana, @corresp, @rendition, @target ...), but
> there's more to the attribute than just its datatype (a URL). And it's
> not just that it points to a <zone> element, either. After all, if a
> piece of software needs to know what kind of element a pointer attribute
> points to, it can just took up the URL and see - find the element whose
> @xml:id attribute matches the value given in the attribute, and see the
> element's name. So there's no real need to define a specific attribute
> just to point to elements of a particular type. For example, we have
> @decls attributes that can point at a variety of elements, including
> bibl and textClass. We don't have a separate @biblDecls attribute to
> point to bibl elements, and a @textClassDecls attribute to point to
> textClass elements.
> So in general the name of a pointer attribute doesn't just indicate the
> type of the element which it links to, but rather indicates the nature
> of the link between the 2 elements. In the case of @decls, the nature of
> the relationship is that the element with the attribute is described by
> the element pointed to. In the case of @facs, it seemed to me, the
> relationship was that the element pointed to was a "facsimile image" of
> the encoded text.
> > > Why should people not be allowed to use @corresp or @ana or whatever to
> > > link the facsimile elements?
> > >
> > Because @facs is defined specifically to link facsimile elements. I
> > suppose one could use @corresp or @ana (or whatever) to do this, but
> > why, when @facs is there? If one could use @corresp, why bother having
> > @facs at all?
> I would definitely use other attributes (e.g. @ana or @corresp) in
> certain situations in order to encode the fact that a piece of text is a
> description of a zone rather than a transcription of it.
> For example, imagine I have a TEI facsimile documenting a collection of
> I might want to ask "who are all the people in the paintings?" or
> "where, in which paintings is the madonna depicted?" I could do this for
> instance if I have a listPerson in my teiHeader, containing person
> elements, each linked with a @corresp to the zones in which they
> I might want to be able to list the articles in my document which
> describe a particular painting.
> I might want to see all the text which actually features in a particular
> painting. There's an art gallery right next door to where I work which
> has this stunning work by a famous NZ artist:
> Unfortunately, you can't read all the text because some of the text is
> small and the painting itself is 10m wide - this is where a TEI
> transcription would help.
> I might want to see all the commentary on a particular painting.
> Or I might want to extract images of all the artist's signatures. I
> would need to identify the zones which covered the areas of the
> paintings in which the signatures appeared. In this case, the <signed>
> elements in my texts would indeed be transcriptions of the paintings, so
> I would use @facs:
> <signed facs="#painting1-sig"><name>Picasso</name></signed>
> I could go on and on, but I think you get the idea. All of these kinds
> of relationship (depiction, transcription, commentary) are valuable for
> some purposes, and I might want to use all of them in the same TEI text.
> So my question is: if I am restricted to using a single generic linking
> attribute, how can I distinguish these different relationships if I want
> to? How can I build software systems that can intelligently deal with a
> text that's been marked up in all these ways?
> I know what I intend to do - it's to use different linking attributes to
> cover these different semantics, and use @facs only to document
> similarity, and I guess use @ana for commentary.
> Conal Tuohy
> New Zealand Electronic Text Centre
Dot Porter, University of Kentucky
Collaboratory for Research in Computing for Humanities
[log in to unmask] 859-257-1257 x.82115
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
[log in to unmask]