Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use of msFrag #368

Closed
thea-m opened this issue Mar 21, 2017 · 7 comments
Closed

use of msFrag #368

thea-m opened this issue Mar 21, 2017 · 7 comments
Assignees
Labels
encoding how to encode this? probably emerging requirement for guidelines mss related to manuscript descriptions

Comments

@thea-m
Copy link
Contributor

thea-m commented Mar 21, 2017

Question arrising from BNFet165#p4_i1 (https://archive.org/stream/manuscritsorient00bibl#page/266/mode/2up), which contains several leaves that were detached from BNFet45#ms_i1.1 (https://archive.org/stream/manuscritsorient00bibl#page/42/mode/2up):

I have just stated this information in a note in both mss records, but maybe msFrag should be used here?

Our guidelines state that "msFrag can be used when there are at least two parts of one manuscript kept in different repositories.", but the TEI guidelines state that "The msFrag element may be used inside msDesc when encoding one or more fragments of a scattered or fragmented manuscript. The fragment(s) described in a single msDesc element may be held either at several institutions or at a single institution, so different call numbers may be attached to the fragments. " - this seems to apply to my case.
What do you think?

@thea-m thea-m added encoding how to encode this? probably emerging requirement for guidelines mss related to manuscript descriptions labels Mar 21, 2017
@thea-m
Copy link
Contributor Author

thea-m commented Mar 21, 2017

see also #369

@eu-genia
Copy link
Contributor

i read from the TEI guidelines in the sense that one creates one record for the "abstract" original manuscript as it used to be, which consists then of msFrag each with its own idno/call number.

@eu-genia
Copy link
Contributor

like the Codex Suprasliensis example they provide (the Codex only exists as a virtual reconstruction):

<msDesc>
 <msIdentifier>
  <msName xml:lang="la">Codex Suprasliensis</msName>
 </msIdentifier>
 <msFrag>
  <msIdentifier>
   <settlement>Ljubljana</settlement>
   <repository>Narodna in univerzitetna knjiznica</repository>
   <idno>MS Kopitar 2</idno>
  </msIdentifier>
  <msContents>
   <summary>Contains ff. 10 to 42 only</summary>
  </msContents>
 </msFrag>
 <msFrag>
  <msIdentifier>
   <settlement>Warszawa</settlement>
   <repository>Biblioteka Narodowa</repository>
   <idno>BO 3.201</idno>
  </msIdentifier>
 </msFrag>
 <msFrag>
  <msIdentifier>
   <settlement>Sankt-Peterburg</settlement>
   <repository>Rossiiskaia natsional'naia biblioteka</repository>
   <idno>Q.p.I.72</idno>
  </msIdentifier>
 </msFrag>
</msDesc>

@eu-genia
Copy link
Contributor

(Ullendorff's split scroll might fit, if one describes it as one scroll consisting of two msFrag, the rebinding of several fragments of various mss in another codex sounds like a different case)

@PietroLiuzzo
Copy link
Member

I have no objection to the use of msFrag here, although I think the way you have stated this in your file is fine. It might be also a topic worth posting to the TEI list, to see what people have been doing in such cases.
In the ref you could have pointed to BNFet45#ms_i1.1 rather than just BNFet45, or did this generate problems?

@thea-m
Copy link
Contributor Author

thea-m commented Mar 27, 2017

corrected the ref

@PietroLiuzzo
Copy link
Member

PietroLiuzzo commented Mar 30, 2017

  • encode the two ms with msFrag for the part which is not there any more and msPart for the second manuscript
  • document in GL decision to encode as msPart in second ms and as msFrag in the first ms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
encoding how to encode this? probably emerging requirement for guidelines mss related to manuscript descriptions
Projects
None yet
Development

No branches or pull requests

4 participants