scta/edf-schema

edf-schema's Issues

should header be called toplevel

header is often reserved for technical data or metadata about a file itself.

We're going to need a place, for example, to indicate which schema this file follows, the date it was created, etc. This seems like header information.

Perhaps topLevel information belongs within the "body" as "toplevel information" or data that applies to the first div since the first

in the body could (or should) represent the top level expression.

Multilingual titles

Would it be possible to have a way of creating different language versions of titles (including translations of the question titles and similar text heading stuff)?

<titleStmt>
  <structureTitle n="1" label="articulus">
    <title xml:lang="en">Sentences Commentary</title>
    <title xml:lang="la">commentarius sententiarum</title>  
  </structureTitle>
  <descriptiveTitle>
    <title xml:lang="en">Abbreviation</title>
    <title xml:lang="la">Abbreviatio</title>
  </descriptiveTitle>
  <questionTitle>
    <title xml:lang="en"/>
    <title xml:lang="la"/>
  </questionTitle>
</titleStmt>

Update <questionListOriginalEditor>

Should we change the field name of <questionListOriginalEditor> to <questionListEditor>?
If the <questionListEncoder> is identical it is clear that the encoder is also the editor, otherwise it is a copy of an already existing list. Is it too ambiguous when it has two different functions in that way?

Fields for contributor attributions

Should the toplevel div have some fields for the creators of the files and its data?

Basically I'm thinking of versions of

<questionListSource></questionListSource>
<questionListOriginalEditor></questionListOriginalEditor>
<questionListEncoder>Jeffrey C. Witt</questionListEncoder>

e.g.

<div id="wodehamabbreviatio" type="abbreviatio"> <!-- top level expression -->
  <!-- All the other things -->
  <encoder>Jeff Witt</encoder>
  <contentSource>Brag McProudlane</contentSource>
</div>

Item with subordinate structural elements

This is part of the problems discussed in #3 and #7.

I have a text which regularly presents an item with subordinate questions. The structure can look like this:

Question: Can there be a science of the soul?
  Sub-question 1: Whether we have knowledge about the soul.
    Rationes principales (contra et pro)
  Sub-question 2: Whether it is an inborn knowledge.
    Rationes principales (contra et pro)
  Sub-question 3: Whether it is acquired by the substance of the soul or an external species
    Rationes principales (contra et pro)
  Ad primam quaestionem: Solution and refutation of rationes.
  Ad secundam quaestionem: Solution and refutation of rationes.
  Ad tertiam quaestionem: Solution and refutation of rationes.

As the solutions and refutations of each of the subordinate questions comes after the presentation of all three I will maintain that this is one coherent item.

I realize/assume that items cannot be nested. But how would we then encode this?
I suppose you could say something like this:

<item id="xx" type="quaestio">
  <fileName filestem="xx"/>
  <title>Utrum possit esse scientia de anima</title>
  <questionTitle>Utrum nos habeamus cognitionem de anima.</questionTitle>
  <questionTitle>Utrum sit nobis innata.</questionTitle>
  <questionTitle>Utrum per substantiam animae aut per speciem.</questionTitle>
  <hasWitnesses>
    <witness ref="#O">
      <folio c="b">100r</folio>
      <folio>100v</folio>
      <folio c="a">101r</folio>
    </witness>
  </hasWitnesses>
</item>

But obviously it would be nice to be able to say where each sub-item starts with a folio reference. That can't be done with this encoding. Any good alternative (that does not include nesting the items)?

Content of the type attribute on the top level div

<div id="wodehamabbreviatio" type="abbreviatio"> <!-- top level expression -->

Does this have a simple answer? Abbreviatio covers a type of text that occurs often in the sentences context, but would never happen (to my knowledge) in a Aristotelian commentary. So this type cuts in at a maybe arbitrary level, as you might also write "sentence-commentary" here, or what?

Would other possible values be something like "quaestiones" and "expositio"?

title vs short title vs long title vs. abbreviated short title

I think the EDF spec should declare the kind of "title" that goes in the <head> or <title> field.

Namely, I think we should specify that this should be the "short title"

By short title I mean just the title of the specific sections, e.g. "caput primus", "articulus primus", etc., as opposed to a long title, which might be "Sentences, Liber I, Distinctio 1, Caput 1".

By mandating that all <title> or <head> contain only a short title, processors can reliably construct the long title by concatenating all of the ancestor short titles together.

But if there is no specified practice here, then a processor cannot reliably construct the long title.

While on the subject we might also want to introduce a filed called "abbreviated short title", so that an "abbreviated long title" can also reliably be constructed. The abbreviated title for "articulus primus" might be "A. 1", this way a processor could construct a "long abbreviated title" like "Sent., L. 1, D. 1, C. 1" etc.

schema should enforce unique values for ids in both 0.0.0 and 1.0.0 relaxng

schema should enforce unique values for ids in both 0.0.0 and 1.0.0 relaxng otherwise we get problems like scta/scta-projectfiles#37 and scta/scta-projectfiles#36

Support for `<title>` field in an `<item>`

Should we add support for titles as well as question titles?
Almost any other kind of text that a work of quaestiones will be structured with heading titles. Alternatively the <questionTitle> could also just be <title>? I don't know if it may be an advantage to be able to differentiate the two types of elements. You might maybe imagine a situation where a item has both a title and a questiontitle, but I don't recall that from my material (where it would be a more general heading).

Support `<unclear>`

Currently the schema does not accept the <unclear>. It should be possible to indicate passages where the encoder/editor is uncertain about the phrasing of a question or title.

Alternative folio indication in item manifestation block

<folio c="b">1r</folio> <!-- is there a more efficient way to do this -->
<folio>1v</folio>
<folio>2r</folio>
<folio>2v</folio>
<folio>3r</folio>
<folio>3v</folio>
<folio>4r</folio>
<folio>4v</folio>
<folio c="a">5r</folio>

What does this mean? Is it required for other reasons to write out every folio explicitly, or would it suffice to just indicate the first and last?

Value for topleve div @type not available in projectfiles

<div id="wodehamabbreviatio" type="abbreviatio"> <!-- top level expression -->

The information for @type="abbreviatio" is not available in the current projectfiles.

item/fileName

Is the item/fileName field superfluous in the new EDF system??

questionTitle vs subtitle

Should EDF 1.0.0 continue to use questionTitle for subheadings or do we need something more generic like "subtitle"?

Is there something about important about a questionTitle that makes it different from a subtitle? Are there cases where there could be both a subtitle and questionTitle? (i'm not sure I can think of any)

This should also affect lbp-schema 1.1.0 discussions, regarding the @type of which currently uses question-title to indicate a the title of question and de facto all subtitles.

Support lemma text in items

Say we have a text that starts like this:

Deinde dicit Philosophus “Sensibilibus autem” et cetera. Ad hoc quaeritur utrum sensus possint ...

Could we mark that up along those lines:

<item id="da-317-l1q1" type="quaestio">
  <fileName filestem="da-317-l1q1"/>
  <title>Liber 1, Quaestio 1</title>
  <lemma>
    <quote>Sensibilibus autem</quote>
    <bibl>
      Arist. DA II.5, xxx
    </bibl>
  </lemma>
  <questionTitle>
    Utrum sensus possint ...
  </questionTitle>
</item>

Of course the content of the lemma field is up for debate, I just would like a way of encoding those references when they are present.

questionTitle @type="original" and @type="supplied"

There some discussion about interest in being able, within and EDF to differentiate between original and supplied questionTitles.

Original questionTitles would indicate that there is some evidence this is a title explicitly given by the expression creator

while supplied questionTitle have been supplied purely for navigational aid.

An @type attribute seems like a reasonable solution

should parentWork designation be mandatory or optional

decisions need to be made here about whether a "parentWork" is a mandatory or optional field

• a work is identical to a workGroup except that it can only take expressions as children, while workGroup can take other workGroups, works, or expressions as direct children.
• In many cases a work only has one expression as thus the relationship is one to one and feels burdensome to record.
• However there are many cases where a work is need to categorize expressions, like Wodeham's Ordinatio and Abbreviatio. Without a concept of work and a canonicalExpression, full text search results could become filled with redundancies. It will be ideal to have a way to filter out non-canonicalExpressions.
• Pros and Cons: Making a parent work "optional" creates complications when writing queries. Making a parent work group "required" creates an extra layer that can often feel redundant.

Right now the project file has a field for parentWorkGroup.

But if a parentWork is stated, the parentWorkGroup should be inferred from the description of the work not the expression, and therefore the field should be removed.

if parentWork is option, the EDF file will need to support both a parentWorkGroup and parentWork field.

Add possibility of editing contributor on the item and intermediate div levels

This makes it possible to indicate that a section of a text is written by somebody else than the general author.

But how about disputed authorship attributions?

Pseudographical attribution registration

During our discussions it was suggested to add a field indicating whether the texts is pseudographically attributed to an author.

I guess it would be a property on the <contributor> element?

A possibility could be an attribute like @attribution with a selection of possible values, such as:

• false
• dubious
• possible
• certain

Certain could be the default, that would normally not need to be specified.

This would make it possible to model a range of possible authors like this:

<contributor attribution="possible">Richard Rufus</contributor>
<contributor attribution="possible">Petrus Hispanus Portugalensis</contributor>
<contributor attribution="dubious">Petrus Hispanus (later Pope Pius XI)</contributor>

Would this be the right level in the system to register this sort of information??

My personal question about this approach is that the source for the type of attribution would not be apparent. But I'm not sure that is a level of granularity that we want here, as that implies a system of registering modern literature that is not developed now.