- When you have
<supportDesc material="paper">
<support>
<material>Paper</material>
...
</support>
</supportDesc>
and there is no further information in <material>
, than Paper or
Parchment I suggest to remove the element material entirely.
Or to remove material="paper"
and to have
<supportDesc>
<support>
<material>Paper</material>
...
</support>
</supportDesc>
This information should be unified somehow, but to repeat one and the
same data makes no sense.
If, however we have
<supportDesc material="mixed">
<support>
<material>Paper</material>
...
</support>
</supportDesc>
then we should write some more information, of course. The same is valid
if we would like to have some more data about the paper or parchment.
Then we will need:
<supportDesc material="paper">
<support>
<material>Paper is of low quality</material>
...
</support>
</supportDesc>
This situation is more complicated because there are several possible variants, and I agree that the most important thing is for us to be consistent. Your examples above are of three types:
- Attribute and element are identical and simple, e.g., both say just "paper".
- Attribute is "mixed" and there are multiple elements.
- Attributes is simple (e.g., "paper") and element is more detailed (e.g., "paper is of low quality")
We might want to approach this question by asking how we want to use the values. Here is a proposal (for discussion; I don't mean to suggest that it is necessarily what we should do):
- The
@material
attribute on the <supportDesc>
element is for structured search and retrieval. For that reason, it's a token list drawn from a fixed inventory of strings: "paper", "parchment", and whatever else might actually occur (stone? wax? birchbark?). Because it is a token list, we would not use a value like "mixed"; if a manuscript includes both parchment and paper, we would write <supportDesc material="parchment paper">
. The order of the values in a token list is not informational, so "parchment paper" and "paper parchment" are equivalent. The attribute is required and the value must include at least one token from the allowed list.
A: I don't quite understand what is wrong with "mixed", but anyway I tried to write <supportDesc material="parchment paper">
, but it triggers immediately an error. According to TEI Schema:
attribute material { "paper" | "parch" | "mixed" | [teidata.enumerated](https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-teidata.enumerated.html) }?
,
https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-supportDesc.html
Attributes using this datatype must contain a single ‘word’ which
contains only letters, digits, punctuation characters, or symbols: thus
it cannot include whitespace.
That means that only one word here is allowed. So, if we would like to use an attribute here which is different from paper or parch, we can use just mixed. The other way around is to change the schema for supportDesc? Should we do it?
- The
<material>
child of <support>
is for human eyes, that is, it's what we render in the codicological description. It is optional, but whether we use it is governed by the following considerations:
a) Where there is a single material and no supplementary information (e.g., paper), we omit the <material>
element. In the codicological description we'll upper-case the value of the attribute. This lets us avoid the duplication. We can validate this with Schematron: if the count of tokens in @material
is not equal to 1
, there must be at least one <material>
element.
b) Whether there are multiple materials, the @material
attribute contains more than one token and a separate <material>
element is required for each type of support. If, for example, the manuscript is on a combination of parchment and paper, there will be two tokens in the @material
attribute value and at least two <material>
elements. There might be more than two if, for example, there are multiple types of paper.
c) Even when there is one type of material, the <material>
element can be used if the description presented to humans should be more detailed than what the attribute allows. For example, the @material
value might be just "paper", while the content of the <material>
element would read something like "Paper of poor quality".
A: David, you describe very good the possible situations. So I will suggest:
a) You know that material is paper or parchment, but you have no further information, then encode this as:
<supportDesc material="Paper">
<support>
...
</support>
</supportDesc>
or
<supportDesc material="Parchment">
<support>
...
</support>
</supportDesc>
With upper case letter.
b) You have a mixture of paper and parchment. Here we should decide whether we will change the model of supportDesc allowing both words as value of material="Parchment Paper"
(upper case), or we will stick with the value "mixed". (If we decide to change supportDesc I don't know what kind of attribute class should be this allowing us to have two words as attribute value).
What do you think? Then, as you suggested we will have two elements (it is repeatable).
c) You have some more information about paper, parchment, etc. Encode this as:
<supportDesc material="Paper">
<support>
<material>Paper is of low quality</material>
...
</support>
</supportDesc>
So, in principle we should decide whether we would like to change the model for supportDesc or leave it as it is?
- Current possibility:
<supportDesc material="mixed">
<support>
<material>Paper is of low quality</material>
<material>Thin parchment. There is almost no distinction between the flesh and hair side ...</material>
...
</support>
</supportDesc>
- Changing
@material
:
<supportDesc material="Paper Parchment">
<support>
<material>Paper is of low quality</material>
<material>Thin parchment. There is almost no distinction between the flesh and hair side ...</material>
...
</support>
</supportDesc>
If we would like to retain both views: description of MS as database and description of MS as user perspective (reading as text), maybe the second one is better. What do you think?