headers
Tara Andrews | 1 Jan 2009 20:37
Picon
Picon
Favicon

Sigla in manuscript description files

This should (I hope) be a very easy question for those of you who are  
checking email over the holidays.

I have a set of TEI files that are transcriptions of manuscript copies  
of a particular history, one file per manuscript.  I'm working on  
creating a critical edition from these manuscripts, and so I want to  
assign sigla to them, and I want to make a note of what sigil I've  
assigned somewhere in the <teiHeader/>.  What is the best way for me  
to stick this in?

Happy new year to all (and happy leap second to all who observed it  
last night),

-tara
Permalink | Reply | 2 comments |
headers
Dot Porter | 1 Jan 2009 21:55
Picon

Re: Sigla in manuscript description files

Hi Tara,

I've had a similar project, and what we did was provide a witness list
in the front matter of each file which includes the sigla for all
manuscripts in the edition as the unique xml:id for each witness - it
looks pretty much exactly like the example given in the listWit
description in the Guidelines
(http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPWL),
although we put the manuscript names as the content of <witness>. We
then pointed  <at> ed on pb and lb, and  <at> wit on rdg, to the xml:id of the
corresponding witness for that file.

Now that I think about it, we didn't specifically link the witnesses
in the listWit to the msDesc in the headers, but I suppose one could
do this using a  <at> corresp on msDesc to point to the xml:id of the
corresponding witness.

Another option, if you don't want to have a complete witness list,
could be to use the sigla as the xml:id for the msDesc in each header.

If you're looking for a way to identify sigla that doesn't involve
providing them as xml:ids - I don't know, although I bet someone else
can suggest one.

Hope this helps,

Dot

On Thu, Jan 1, 2009 at 2:37 PM, Tara Andrews
<tara.andrews <at> linacre.ox.ac.uk> wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tara Andrews | 1 Jan 2009 23:53
Picon
Picon
Favicon

Re: Sigla in manuscript description files

Hi Dot,

Thanks very much for this.  I do want them to be xml:ids, though I  
wasn't thinking about that when I wrote the first email.  Making each  
sigil the xml:id for its corresponding msDesc is so beautifully simple  
it eluded me.  (I can then use that to generate the <listWit/> in the  
file that will represent the edition itself, as an added bonus.)

-tara

On 1 Jan 2009, at 20:55, Dot Porter wrote:

> Hi Tara,
>
> I've had a similar project, and what we did was provide a witness list
> in the front matter of each file which includes the sigla for all
> manuscripts in the edition as the unique xml:id for each witness - it
> looks pretty much exactly like the example given in the listWit
> description in the Guidelines
> (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPWL),
> although we put the manuscript names as the content of <witness>. We
> then pointed  <at> ed on pb and lb, and  <at> wit on rdg, to the xml:id of the
> corresponding witness for that file.
>
> Now that I think about it, we didn't specifically link the witnesses
> in the listWit to the msDesc in the headers, but I suppose one could
> do this using a  <at> corresp on msDesc to point to the xml:id of the
> corresponding witness.
>
> Another option, if you don't want to have a complete witness list,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tara L Andrews | 3 Jan 2009 18:10
Picon
Picon
Favicon

witDetail, and punctuation in text criticism

As I said in my last email to the list, I'm working on a project in  
which I have a bunch of TEI "manuscript" files, and I'm trying to  
produce a critical edition from them.  I've run into one apparent bug  
and one conceptual problem on which I'd like advice from anyone who  
has done this sort of thing before.

The bug is in the definition of <witDetail/>.  The guidelines say this  
about its attribute 'wit':
" <at> wit  (witnesses) indicates the sigil or sigla for the witnesses to  
which the detail refers."
...but the RNG schema only allows a single data pointer as the value  
of this attribute.  This is in contrast to <rdg/> and its friends,  
which allow multiple sigla to be listed (e.g. <rdg wit="#A #D  
#Cz">...</rdg>).  Or am I misunderstanding something?  I've modified  
my local copy of the schema, but wonder if this should be fixed in the  
published ones.

Among other more canonical uses, I am using the <witDetail/> tag to  
record punctuation variants.  Rather than making each punctuation mark  
a separate reading, which I have found extremely cumbersome from the  
point of view of text collation, I have been adding a <witDetail/> tag  
on any word that has punctuation in any of the manuscripts.  So a  
typical reading will look something like this (apologies for the  
strange words; this is transliterated Armenian):

      <app xml:id="App481">
          <rdg wit="#Jer #K">
            <w>zastoucoy</w>
          </rdg>
          <rdg wit="#V #Y">
(Continue reading)

Permalink | Reply | 4 comments |
headers
Syd Bauman | 3 Jan 2009 22:03
Favicon

Re: witDetail, and punctuation in text criticism

> The guidelines say this about its attribute 'wit': " <at> wit
> (witnesses) indicates the sigil or sigla for the witnesses to which
> the detail refers." ... but [it is declared as only 1
> data.pointer].

Looks like a corrigible error to me. I'd say wit= should be delcared
as 1 or more data.pointers.
Permalink | Reply | 0 comments |
headers
Peter Boot | 4 Jan 2009 13:56
Picon
Picon
Favicon

Re: witDetail, and punctuation in text criticism

Hello Tara,

Tara L Andrews schreef:
>      <app xml:id="App481">
>          <rdg wit="#Jer #K">
>            <w>zastoucoy</w>
>          </rdg>
>          <rdg wit="#V #Y">
>            <w>astoucoyn</w>
>          </rdg>
>          <witDetail target="#App481" wit="#K" type="punctuation">:</
> witDetail>
>          <witDetail target="#App481" wit=" #V #Y"
> type="punctuation">,</witDetail>
>          <rdg wit="#X" type="omission"/>
>      </app>
> 
> which gives the following witnesses:
> Jer:    zastoucoy
> K:    zastoucoy:
> V:    astoucoyn,
> X:    (om.)
> Y:    astoucoyn,
> 
> So before I go too much farther with this sort of thing, I am
> wondering: is there a generally accepted way to handle punctuation
> variations in text criticism?  To handle punctuation at the level of
> semantic markup at all?  How have other people done this, if at all?

The witDetail element is synonymous with <note type='witnessDetail'>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dot Porter | 5 Jan 2009 18:38
Picon

should decoNote be a member of model.noteLike?

Hello list,

I am wondering vaguely if decoNote should be added to model.noteLike.
It seems to me that decoNote is syntactic sugar for
note <at> type='decoration', in which case it should be able to go where a
regular note can go. This comes up because I would like to be able to
place decoNote inside p, which I can't do at the moment. I could just
use note <at> type='decoration', but I'd rather use the note defined
specifically for describing decorations.

Thoughts? Objections to submitting this as a feature request?

Thanks,
Dot

--

-- 
*******************************
Dot Porter, MA, MSLS
Metadata Manager
Digital Humanities Observatory (RIA)
Pembroke House
28-32 Upper Pembroke Street
Dublin 2, Ireland

-- A Project of the Royal Irish Academy --

Phone: +353 1 234 2444
Fax: +353 1 234 2400
Email: dot.porter <at> gmail.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lou's Laptop | 5 Jan 2009 20:08
Picon
Picon
Favicon

Re: should decoNote be a member of model.noteLike?

Dot Porter wrote:
> I am wondering vaguely if decoNote should be added to model.noteLike.
> It seems to me that decoNote is syntactic sugar for
> note <at> type='decoration', in which case it should be able to go where a
> regular note can go. 
That's a nonsequitur. The reason for having decoNote at all (as with 
other xxxNotes) is precisely that it *doesn't* go where other notes go. 
It's specialised as to location as well as content -- it's a constituent 
of <decoDesc> and should not be found floating around inside <p>s elsewhere.

> This comes up because I would like to be able to
> place decoNote inside p, which I can't do at the moment. I could just
> use note <at> type='decoration', but I'd rather use the note defined
> specifically for describing decorations.
>
>   
But it's not just a note for describing decorations. It's for describing 
a particular category of decoration within a structured summary 
description of the decorative aspects of a manuscript.

> Thoughts? Objections to submitting this as a feature request?
>
>   
I've certainly no objection of course to your making this feature 
request. Maybe others will agree with you. But I don't think I do.
Permalink | Reply | 0 comments |
headers
Sebastian Rahtz | 5 Jan 2009 22:05
Picon
Picon
Favicon

Re: 2 problems in both Romas

Piotr Bański wrote:
> When I want to change something in the  <at> type attribute of <seg/>, the
> default Roma shows a blank page.
> 
> While the oucs Roma says this:
> 
> Fatal error: Uncaught exception 'DOMException' with message 'Invalid
> Character Error' in /usr/share/tei-roma/roma/romadom.php:788 Stack

these are bad!

I'm working on it tonight, but
it is not obvious so far what is wrong

--

-- 
Sebastian Rahtz
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente
Permalink | Reply | 0 comments |
headers
Greg Murray | 6 Jan 2009 17:09
Favicon

Synchronizing a TEI transcription to an audio recording

The TEI Guidelines have an entire chapter devoted to transcribing 
speech, but the subject of synchronizing that transcription to a 
corresponding digital audio recording is presumably outside the scope of 
the Guidelines, so understandably I can find only one brief mention, 
near the end of this section:

http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html#SASYMP

That example shows SMIL markup providing anchors to specific points in 
the audio, while TEI <link targets="..."> markup is used to point to 
those anchors.

Can anyone offer further info, or other suggestions? Or perhaps even 
point me to documentation (best practices recommendations, local markup 
guidelines, etc.)?

Thanks,
Greg Murray
University of Virginia Library
Permalink | Reply | 2 comments |

Gmane