Danish Letter 19310818

[RJP43]

Source Materials:

19310818 Folder
MIWschema.rng

[ekupchella]

One thing Tina and I noticed about the schema validation process is that not only did it fire up, but it fired up on the element because where it was, it wasn't well formatted. We talked about it, and because this is sort of a new thing for all of us, we think that this particular error existed because it was an issue with the document not being "well formed". We don't know a ton about encoding, but we thought that would exist because formatting has been the most foundational part of our understanding when it's come to encoding. That's been one of the key lessons so far, so it makes sense that we'd come back to an idea that we know and challenge us to master it.

[ekupchella]

My Two Reports:

1. One thing that caught my eye was definitely publicationStmt. I worry that, because the stakes are high as this is an academic project, that something could go wrong and we could misattribute something, but Dr. Caughie has always stressed the importance of correctly sourcing and having sources to back up statements, so knowing how important that is in this work made that particular piece stand out to me.

2. The second was sourceDesc. In this area, we're tasked with talking about sourcing and narrowing down the specific time and place as well as context. I think that's a really big deal here, context. It's one of the things that's just as relevant in the encoding part of class as it is in the literary part of class, and as someone who isn't able to connect the two components very well, that was a common ground for me when I was working on this. It was easy to get disconnected sometimes from the book, but this reminds me that it's the same set of materials that we're working with.

[tinatiehen]

List of unique people:

1. Maria Garland, key = "garlandM", mentioned: 1
2. Lili Isle Elvenes, key = "lili", mentioned: 3
3. Kristin Jacobsen, no ID, mentioned: 1
4. Maiken Boysen, no ID, mentioned: 1
5. Tyler Monaghan, no ID, mentioned: 1
6. Professoren (the professor), key = "warnekros", mentioned: 2
7. Herr Oberartz (the head doctor), key = "kreutz?", mentioned: 2

List of unique places:

1. Dresden, key = "dresden", mentioned: 2
2. hemmilge Adresse (secret address), no ID, mentioned : 2
3. Tyskland (Germany), key = "germany", mentioned: 2
4. det Kongelige (Royal Theatre), key = "theatreRoyal", mentioned: 2

[tinatiehen]

My Two Reports:

1. The first thing that stands out to me is the respStmt. Our project constrains this element by linking two critical elements: resp and persName, which are subsequently unique in themselves given circumstantial information. This series of information, as suggested by TEI guidelines, helps to identify the name and affiliation of an editor. In the case of our project, this constraint seems to be linking the responsibility of translation with the editor or translator who completed the task, as well as the date it was completed.

2. The second thing is the fileDesc. This element contains a broad range of information; thus, it essentially constrains all the elements that would provide context or background prior to the actual text document and does not necessarily include specific attributes and their values. For example, we include respStmt in this root category. The fileDesc element corresponds to the description "areas" for a clear, concise framework of the text to be easily referenced by anyone interested in such information.

[tinatiehen]

Elizabeth accurately highlighted our concerns when implementing the MIW schema into our Danish Letter. To elaborate, the specific error we encountered was present in both the English and German versions, so 2 errors in total. The error was the uncertainty with this element: persName key="kreutz?">Herr Oberartz</persName where the attribute value has a question mark. The error in English was the same: persName key="kruetz?">the head doctor</persName. Regardless, the schema was associated into XML successfully.

[RJP43]

@ekupchella and @tinatiehen well done completing most of the TEI XML Exercise! :tada: The only minor issue with your submission was although you were clearly able to associate the schema in order to determine the validation errors neither of you re-uploaded the correctly associated XML to your team's folder. I went ahead and added the XML with the correct schema line to your folder just to prevent any continued confusion for the next people to work with these files.

For the next assignment, your team will need to reference the latest file added to the Danish Letter 19310818 Archival Materials Folder 📂 -- a screenshot of the TEI header information provided by the project manager, Emily Datskou. As a team, you will work together to create a <teiHeader> element for Danish Letter 19310818 using the information provided by Emily, the existing XML encoding, photograph(s) of the letter (a.k.a the facsimile images), and the translation/transcription documents.
(⬆️ all available in your text's folder linked above ⬆️)

Be sure to reference the TEI Header Exercise in order to let each other, @ProfPLC, and I know what tasks you each are comfortable with completing by Tuesday (2/26) 📆. Please remember the main goals in all of our assignments are team communication 💬 and collaboration 👐.

_Note: the TEI header template is available in Thursday's lesson on Capturing Metadata and as a download-able XML file containing the template <teiHeader>._ Happy coding! 💻 😃

[tinatiehen]

Elizabeth and I discussed in class that we will equally divide our TEI header tasks within our XML file, I created lines 1-43 in the TEI header, and Elizabeth took 44-96. I sent my lines to Elizabeth and she will be uploading the xml tei header file to our issue.

[tinatiehen]

A TEI element I noticed that is not utilized in our TEI header is <listPerson>. This element is described by the TEI guidelines as containing a list of descriptions, "each of which provides information about an identifiable person or a group of people, for example the participants in a language interaction, or the people referred to in a historical source." I thought it was interesting we do not use <listPerson>, given our Danish letter includes multiple names under the same description, just coded on separate lines. We could use this element as a more concise, definitive lineup of the people involved for a specific task. For example, a list of engaged learners could be coded with <listPerson>, which even allows for the use of <listRelation> where we could throughly describe the relationship between engaged learners as team-members, or translators as professional. @ekupchella what do you think?

[RJP43]

@tinatiehen @ekupchella I love the idea of dividing the file up based on lines. What a nice use of the line numbering available in oXygen as well as here on GitHub. Great use of the interfaces we are using!

@tinatiehen 🎉 fantastic statement regarding the element <listPerson>. I am really pleased to see you made this observation regarding our complex prosopography situtaion. I am pleased to tell you that if you look at the structure of the LEDA_prosopography.xml, which I mentioned on Tuesday will be linked to every document via our new schema, we are indeed using the <listPerson> element to list all of our contextual characters. I love the idea of doing something similar with our project team information. Thanks for the thoughtful suggestion.

[ekupchella]

Really great points, Tina!

I wanted to focus on how we didn't have to do <schemaRef>. The reason is that we've been talking so much about the meaning of the schema, that is, the organization or structure of our database. It makes sense that we'd probably omit this, as we're just trying to focus on adding new information and things could get confusing, at least in my opinion, if we not only do sometimes tough task work and additionally have to understand how that task relates to everything else. For me, I've liked thinking of our homework as just that homework, and class time is when we can come together to discuss the implications of it. Of course it's always good to have a basic understanding of what the project goals are as we get through this project, but I just like that breakdown and appreciated that the TEIheader outline was minimalist 💯

[tinatiehen]

Elizabeth, great points❗️I agree that referencing a specific schema could not only become repetitive, but the project is constantly improving and changing based on incoming information. That being said, the schema would need to reflect the progress being made and thus, could be modified and become inconsistent for any given xml. However, I find it beneficial to recognize that the <schemaRef> element could offer insight into the hard work that comes with creating and customizing an entire project schema. 💅🏽💅🏽💅🏽

[RJP43]

:tada: This is a fantastic interaction @tinatiehen and @ekupchella! 🎉

[RJP43]

@tinatiehen @ekupchella please be sure to upload your file containing the completed TEI Header before class. I do not see it in your team's folder.