Bertrand Gaiffe asks whether the <recording> element is the best place to store information about the actual sound files in which a recording is stored. There may be several of them for a given recording, and there is no obvious structured way of recording this, and aligning particular parts of a transcript with the relevant files.
He also points out that there is a parallel with the way that images are stored, and associated with a transcript.
Maybe something like the <facsimile> element would be appropriate?
en réfléchissant à l'encodage de l'oral, je suis tombé sur le problème
suivant :
- on peut avoir plusieurs <recording> (si on a plusieurs fichiers sons)
- on peut avoir plusieurs fichiers sons
PB : on veut faire le lien entre un <recording> particulier et un
fichier son particulier.
Normalement, les gens des manuscripts pourraient avoir le même problème...
Ils ont les images d'un manuscripts particulier,
Ils encodent à coup d'appareil critique en faisant référence à plusieurs
manuscripts (définis dans le header).
PB : comment disent-ils que leurs images sont celles de tel manuscript
précis (parmis ceux qui sont référencés dans le header).Et ce à supposer
qu'ils n'aient d'images que d'un seul....
Si la réponse existe pour les manuscripts, elle doit pouvoir se
transposer pour l'oral ; d'où ma question.
Would the discussion benefit from Thomas Schmidt's suggestions in his jTEI paper at http://jtei.revues.org/142 ?
For the record Thomas Schmidt would be eager to coordinate an ISO tc 37 sc 4 project on a TEI customization covering features available in Elan, Exmeralda, Anvil, etc. TEI experts should definitely join. Still in preparation/discussion, but the earlier people raise their hands to contribute, the better.
This is assigned to me, so I'll be happy to be involved, although I wouldn't describe myself as an expert -- I don't know anything about Elan, Exmeralda or Anvil. If there are folks who do, please put your hands up.
In April 2012 Technical Council meeting, it was decided that James Cummings would write to TEI-L asking for people who are interested in participating in a work group on this and on http://purl.org/tei/fr/2724997 . This group should report back to Council with a proposal for discussion at a later meeting.
But now see http://purl.org/tei/fr/3597335 .
Lou has presented a report from the workshop here:
http://www.tei-c.org/Activities/Council/Working/tcw25.xml
Lou Burnard to follow up with group as to their draft “useful document”. See also https://sourceforge.net/p/tei/feature-requests/176/ , which has been closed / merged with this ticket (per Martin Holmes).
Last edit: Syd Bauman 2013-11-13
The ISO WG is still active and the latest version of their document has just appeared at https://docs.google.com/document/d/1BTjYHSiPjD6GhKMNFmZrrvCkLQAa1RK7aGbG5K50uN4/edit?usp=sharing
The google doc at https://docs.google.com/document/d/1BTjYHSiPjD6GhKMNFmZrrvCkLQAa1RK7aGbG5K50uN4/edit?usp=sharing was updated again and progressed at a meeting in Berlin June 24th.
Looking at this bit of the document:
https://docs.google.com/document/d/1BTjYHSiPjD6GhKMNFmZrrvCkLQAa1RK7aGbG5K50uN4/edit?pli=1#heading=h.80clzsvnajnb
which deals with
<annotatedU>
, I see this:"Although the use of
<annotatedU>
is optional, it is not allowed to mix<annotatedU>
and<u>
elements on the top level - i.e. as soon as one<annotatedU>
element is used, all<u>
elements have to be wrapped inside an<annotatedU>
element."Why so harsh? If you have 50 utterances and you only need to annotate one of them, why would you need to nest all the others inside
<annotatedU>
elements? Or have I misunderstood?Closing this ticket since the original issue has been addressed and work on the ISO proposal is being tracked elsewhere.