edf-schema's People
Forkers
stenskjaeredf-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
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.