search

lombardpress / lombardpress-schema

0 stars 2 forks source link

Structural milestones #66

Open stenskjaer opened 7 years ago

stenskjaer commented 7 years ago

Question commentaries are generally structured in the following manner:

I would like to indicate this overall structure by <div> elements. I don't know if @type is the best attribute to indicate this hierarchy, but that is my suspicion. @subtype could also be used, but I think that I prefer to indicate the hierarchy though naming conventions (similar to the typology of reading types) rather than attribute names as the type/subtype division hints at a hierarchy of only two levels. That might not be enough.

A possible general schema could be something like this:

<div xml:id="item-id"> <!-- The top level div of the item -->
  <p>Quaeritur utrum de anima possit esse scientia.</p>
  <div type="rationes-principales">
    <p>Arguitur quod non.</p>
    <div type="rationes-principales-1">
      <!-- The content of the first ratio principalis -->
      <p>De eo quod ...</p>
    </div>
    <div type="rationes-principales-2">
      <!-- The content of the second ratio principalis -->
      <p>Item se quis ...</p>
    </div>
  </div>
  <div type="opposita">
    <p>Oppositum patet per Philosophum et arguitur</p>
    <! -- If more than one argument is presented, they can also be subdivided by @type="opposita-1 .. n" -->    
  </div>
  <div type="determinatio">
    <div type="determinatio-1">
      <p>Intelligendum quod de anima possit esse scientia ... </p>
    </div>
    <div type="determinatio-2">
      <p>Item intelligendum quod ... </p>
    </div>
  </div>
  <div type="ad-rationes">
    <p>Ad rationes</p>
    <div type="ad-rationes-1">
      <p>Ad primum cum dicitur ... </p>
    </div>
    <div type="ad-rationes-2">
      <p>Ad secundum cum dicitur ... </p>
    </div>
  </div>
</div>

In my own context I would use this to enumerate the different structural elements according to a simple numbering scheme reflecting that structure. In the processed text, it might for instance look like this:

Quaeritur utrum de anima possit esse scientia
1 Arguitur quod non
1.1 De eo quod ...
1.2 Item se quis ...

2 Oppositum patet per Philosophum et arguitur ...

3.1 Intelligendum quod de anima possit esse scientia ...
3.2 Item intelligendum quod ...

4 Ad rationes
4.1 Ad primum cum dicitur ...
4.2 Ad secundum cum dicitur ...

Questions:

nivaca commented 7 years ago

I find it useful. But we should have in mind a much wider repertoire of quaestio-divisions:

On Thu, Sep 29, 2016 at 02:53, Michael Stenskjaer Christensen notifications@github.com wrote:

Question commentaries are generally structured in the following manner:

I would like to indicate this overall structure by

elements. I don't know if @type is the best attribute to indicate this hierarchy, but that is my suspicion. @subtype could also be used, but I think that I prefer to indicate the hierarchy though naming conventions (similar to the typology of reading types) rather than attribute names as the type/subtype division hints at a hierarchy of only two levels. That might not be enough.

A possible general schema could be something like this:

Quaeritur utrum de anima possit esse scientia.

Arguitur quod non.

De eo quod ...

Item se quis ...

Oppositum patet per Philosophum et arguitur

Intelligendum quod de anima possit esse scientia ...

Item intelligendum quod ...

Ad rationes

Ad primum cum dicitur ...

Ad secundum cum dicitur ...

In my own context I would use this to enumerate the different structural elements according to a simple numbering scheme reflecting that structure. In the processed text, it might for instance look like this:

Quaeritur utrum de anima possit esse scientia 1 Arguitur quod non 1.1 De eo quod ... 1.2 Item se quis ...

2 Oppositum patet per Philosophum et arguitur ...

3.1 Intelligendum quod de anima possit esse scientia ... 3.2 Item intelligendum quod ...

4 Ad rationes 4.1 Ad primum cum dicitur ... 4.2 Ad secundum cum dicitur ...

Questions:

  • Any thoughts?
  • Should it be part of the schema, or should I just do that in my own context and accommodate my conversion schema accordingly?
  • Is it useful outside the context of Aristotelian commentaries?
  • I guess it is, but I'm not too familiar with the variations in question structure in theological texts, so maybe it should/could be generalized?

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/lombardpress/lombardpress-schema/issues/66, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACM7jU6GdaQVRm-mQjnTBf8pDCpM2i5Cks5qu25pgaJpZM4KJrnE.

jeffreycwitt commented 7 years ago

Hi guys,

Yes. This is definitely something we want. This is why we need an editorial board of the SCTA ontology. Basically we're already set up to do this with the concept of "expressionTypes" we just need to develop an initial list of supported types and then let people create issues when they want a new one added.

I'm already identifying rationes principales exactly as @stenskjaer is doing with the type="rationes-principales".

I'm also using type="articulus", type="dubium", type="quaestio".

I'm not sure it's necessary to add the "rationes-principales-1" because we're identifying types here not unique ids. So each argument here would be an instance of "rationes-principales". In my view, "rationes-principales-1" would only be interesting if you were trying to study all "rationes-principales" that occurred first in ordered list of arguments. But I'm not sure that's a research question. Correct me if I'm wrong.

As you suggest, I also don't think we need to use type and subtype. If we created a hierarchy of types outside the document, then all we need to is identify the div with the "lowest" level type, and the div association with all of the ancestor types can be inferred automatically.

So for example, we might have the following:

  • librum

    • sc-librum
    • sc-librum1 (sentences commentary book 1, which is itself a type of book)
    • sc-librum2
    • sc-librum3
    • sc-librum4
    • da-librum1 (da anima commentary book 1, which is also a type of book) -da-librum1 -da-librum2 -da-librum3

    Now if we want to run a search for all books that were part of a sentences commentary we could look for any div with a type designation that falls under "sc-librum". The same goes for de anima books. But again, if we wanted to study every division that is a "librum" we could just request every div that has a type that falls under "librum".

Nick is right though, there are a lot of different types to consider, especially in later commentaries.

Perhaps we should set up a skype meeting to create a provisional list and a repo where new types could be suggested via git hub issues.

stenskjaer commented 7 years ago

First, I agree completely with both of you that my suggested categories are neither complete nor final. But I find the great variety might present a challenge, since we might not be able to create The List of Structural Elements that will be universally acceptable. I see your point, @jeffreycwitt, about imposing some editorial decisions in this matter, and I would definitely we very willing to discuss those.

But I also think that we might want to be clear which level we are talking at. The categories that @jeffreycwitt suggests seem, as far as I can tell, to be relatively high level. At the level of expressions or items, we can find a good list, I think, that should be able to cover most situations and then have issues for what might come up (as suggested). But I think that the type of elements that I have in mind, and that I also interpret @nivaca to refer to, are to be found at a lower level in the textual tree. I can have an item that is part of a question commentary, and that will of course be of the type quaestio or whatever appropriate category we choose. But that will then also contain further subelements, such as the rationes principales etc. At the same time, I might also very easily have a sententia commentary, a textual exposition that is much closer aligned with the Aristotelian text and composed of lectiones which each present an interpretation of a section of the Aristotelian text. I would probably say that a lectio is an item. But that item might also very well contain a dubium which is structured exactly like a quaestio in a question-commentary, that is with rationes principales, opposita, determinatio and ad rationes.

So I have some questions:

  1. When you mention the category of "rationes-principales", are they then at par with the other categories such as "articulus" or "quaestio" in the hierarchy?
  2. Do we agree that these are actually different structural levels?

From our previous conversations about this I have the impression that these lower level elements should not be stated in a projectfile, but would fit more naturally into the encoding of an item. But I see now, that of course this all depends on how you demarcate an item. If you want to make a "ratio principalis" into an item in itself, that category slips into the projectfile-level.

I wonder whether the schema should include some sort of generic structural element encoding designed to handle the variety of elements of the "lower level" type. An idea would be to employ the @ana attribute and then let the editor declare his structural elements in some appropriate header context. Something like this (I haven't thought about the corresponding header declaration yet):

<div type="generic" ana="#de-intellectio-quaestiones">
...
</div>

This way the list of these elements would be open-ended. The hierarchy would then only be apparent from the relation to parent and child <div>s, and it would be up to the individual processor to figure out how to handle it.

About the numbering: I agree completely with your point about the numbers as part of the type-name. That's a bad idea. For now I have played with the @n attribute in combination with the types I sketched. Since there is a correspondence between rationes principales and their responses in the ad rationes, you cannot rely solely on the position of the element in the tree, as I would like the number of the ad rationes to reflect what it answers rather than its sequential position. So if a question contains two rationes principales which are both answered in the ad rationes but with the order inversed, I want that to be represented thus in the processed text: 

Quaeritur utrum ...
1 Videtur quod non.
1.1 Cum dicit Philosophus
1.2 Omne quod ...

4 Ad rationes.
4.2 Ad secundum cum dicitur 'omne quod'...
4.1 Ad primum ...

But I think that might be a problem/situation particular to my texts, and I won't try to push that too aggressively into the general schema, if you don't recognize the need/situation.

But anyhow. This is all very interesting, and maybe also a bit complicated. So I would surely be interested in talking about these things on Skype.

stenskjaer commented 7 years ago

I'll revive this question with a problem: <p> does not accept the @type attribute. This means indicating the structural elements in that way is invalid.

A possibility would be to use @ana, but as always, that is difficult, as it takes a pointer, so there should be some list of milestone types. It might not actually be a problem in this context, as we might want to maintain a list of structural element types that will make this somewhat self-documenting.

jeffreycwitt commented 7 years ago

That's also annoying. <div> can take @type but not <p>. The must see <p> as an already typed grouping. They probably under stand <p> as

I think what we are trying to do is probably closer to what the TEI expects us to be doing with @ana

We might consider changing to @ana through and then create another "global" include file (like we do with names and works). Then as this list of available of "expression types" gets updated on github, a editor will have access to all available tags via the drop down list provided by Oxygen.

When the script crawls the texts, all the "hashes" will be stripped and the correct value will be recorded.

jeffreycwitt commented 7 years ago

For the moment, I think our build script will work if we keep @type on <div> and @ana on paragraphs. The build script will recognize the difference and respond appropriately. For our experimental work, this will be fine.

Our long term goal should probably be to standardize everything to @ana.

stenskjaer commented 7 years ago

Actually I don't think such a include file with the types necessarily is a bad thing. This lets us document and represent the types in a clear way (and might even be able to let the structure of the reference file reflect an otherwise only implied hierarchy between the different types.

I think that moving towards @ana as a long term goal would be good. (The dangerous question is then, how about our cherished reading-types?)

jeffreycwitt commented 7 years ago

Agreed, I think we should make a file with a flat list of reading types with ids. Then these types can be grouped and regrouped through a serious of relationships in the bottom of the file.

This will allow a type to be grouped (and regrouped) into more than one category. The editor will only need access to the id for the type they are interested. The editor doesn't even to know about all the possible groups and relationships between types.

But we can use subsequent associations and groups to build inferences.

So if an editor uses the label "principal-argument," but later we want to build an application that grabs all "arguments", the computer will be able to include a "principal-argument" alongside all other sub argument types through the associations made in such a file.

stenskjaer commented 7 years ago

Yeah of course, that sounds like a good solution.