The line element, transcription, and the ex element.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

The line element, transcription, and the ex element.

Matthew Davis-2
Hello,

I’ve turned back to working on an archive that uses the embedded transcription model favoring sourceDoc, as seen in 11.2.2 in the guidelines. One thing I haven’t been able to figure out is why elements like del and add are allowed but expand or ex (or for that matter abbr and am) are not.  I was wondering if someone might be able to tell me if there’s a reason why I shouldn’t add a reference to ex and am (or maybe to model.pPart.transcriptional) in model.linePart on the site schema?  It looks like the thought is that abbreviations and expansions are only editorial, but that seems to kind of fly in the face of the idea that this is an embedded transcription, where I would expect expansions to be, well, expanded.  I know it could be argued that’s editorial intervention, but no transcription I’ve worked with ignores expanding abbreviations simply because that’s not on the manuscript page, because it’s understood that the marks on the page indicate the abbreviated letters.  

I could make my xml compliant as-is by wrapping ex in other elements, but I’m not sure why it simply wouldn’t be part of the line. Especially when things like note, which also can be considered editorial intervention, are allowed without an error being thrown.

All best,
—Matt
Reply | Threaded
Open this post in threaded view
|

Re: The line element, transcription, and the ex element.

Elena Pierazzo-3
Dear Matthew,

The rationale you mention below is exactly the one we followed when we created the <line> element: the idea was to allow only elements (and it was super hard to do that too, mind you) that would be needed to represent the document as it is, and therefore limit all editorial interventions in order to avoid as much as possible the problem of overlapping. The example of <note> is kind of special: being a self-contained it does not cause overlapping, and we also considered that annotation are indeed such a basic feature for any kind of text that we needed to keep it. For all other situation we also thought to leave a sort of f an escape window, therefore allowing elements such as <seg> and <mod> that could be used for that purpose.

However, as you correctly state here, there are practical and theoretical implications and complications that might suggest revisit the question in the near future. In fact the other principle we followed was that as soon as people will start to actually use <sourceDoc> they would suggest improvements for things that we didn’t thought of or fully appreciated.

Best
Elena


> Le 26 août 2020 à 22:31, Matthew Davis <[hidden email]> a écrit :
>
> Hello,
>
> I’ve turned back to working on an archive that uses the embedded transcription model favoring sourceDoc, as seen in 11.2.2 in the guidelines. One thing I haven’t been able to figure out is why elements like del and add are allowed but expand or ex (or for that matter abbr and am) are not.  I was wondering if someone might be able to tell me if there’s a reason why I shouldn’t add a reference to ex and am (or maybe to model.pPart.transcriptional) in model.linePart on the site schema?  It looks like the thought is that abbreviations and expansions are only editorial, but that seems to kind of fly in the face of the idea that this is an embedded transcription, where I would expect expansions to be, well, expanded.  I know it could be argued that’s editorial intervention, but no transcription I’ve worked with ignores expanding abbreviations simply because that’s not on the manuscript page, because it’s understood that the marks on the page indicate the abbreviated letters.  
>
> I could make my xml compliant as-is by wrapping ex in other elements, but I’m not sure why it simply wouldn’t be part of the line. Especially when things like note, which also can be considered editorial intervention, are allowed without an error being thrown.
>
> All best,
> —Matt