Key: DMU-CTA De Montfort; IRHT Paris; NLP Prague; OU Oxford; KB Royal Library, the Hague; EAMSS US partners; VL Vatican Library; AP other associated partners; EG Expert group; BFM Marburg

Second Project Meeting, February 26-27, 1999. L’Institut pour recherche et histoire des texts, 40 Avenue d’Iena, Paris

Attending:

Anne Korteweg (KB), Lou Burnard (OU), Richard Gartner (OU), Zdenek Uhlir (NLP), Elisabeth Lalou (IHRT), Muriel Gougerot (IRHT), Pierre Lardet (IRHT), Patricia Stirneymann (IRHT), Consuelo Dutschke (EAMSS), Belinda Egan (EAMSS), Merrilee Profitt (EAMSS, TEI), Peter Robinson (DMU-CTA), Judy Simons (DMU-CTA), Matthew Driscoll (AMI), Dominique Poirel (IRHT)

26 February

PR drew the attention of the partners to the need to complete the first project reporting webpage for each partner. These have now been prepared by the DMU team and it should be very straightforward for each partner to complete these. Partners must also complete the questionnaire on labour costs for EACH person employed under the project and forward this AND a copy of the contract for each person employed to DMU.

Professor Simons then took the partners through the draft consortium agreement. The importance of the Project Coordinating Committee in this was noted, and LB pointed out that this group had not been formally constituted and had not formally met. PR admitted that this was an oversight on his part. It was agreed that the next meeting of all the partners should begin with a formal meeting of the PCC, and that if necessary such a meeting should be called in advance of the next regular scheduled work meeting.

The meeting agreed that the safeguards and controls set out in the Consortium Agreement appeared adequate. PR explained that DMU would draw up the formal agreement in the next few weeks, but that we needed agreement on the IPR aspects of the agreement (the one area where the draft was not applicable). PR placed before the meeting notes on the IPR aspects of the project from the Leicester meeting. There the partners agreed:

1. Standards materials related to the TEI standard, in the form of the TEI Document Type Definition to be developed in partnership with MASTER, and all derivative materials associated with the standard (as: rules files generated from the DTD, subset files of the DTD, documentation of the DTD). The partners agreed that we shall not assert exclusive rights to any of these
2. Software and derived products developed for the project by the partners. The partners agreed that all software and derived products are jointly owned by all partners. The partners will determine an exploitation agreement which will set out transfer and exploitation rights for all such products after the project’s conclusion.
3. The Intellectual Property Rights in the manuscript records made as part of the MASTER project. We agreed that these will be the property of the partner contributing these to the project. Each partner contributing such records will grant all other partners non-exclusive right to the use of these records for demonstration and development purposes. This right to non-exclusive use for demonstration and development purposes will continue beyond the end of the project. Other use of the records by the partners after the end of the project will be determined in the exploitation agreement.

The following modifications were made by the partners:

• We should specify that not only do we not assert exclusive rights to any of these, we also believe that no-one else should assert any such right (PR expressed doubt as to whether this statement could have any legal force, but agreed to pass this onto the legal folks for their opinion)
• We should specify that the exploitation agreement will be concluded within twelve months of the end of the project
• We should specify that ‘This right to non-exclusive use for demonstration and development purposes will continue beyond the end of the project for a period to be determined by the exploitation agreement’

We agreed (as is legally the case, in any matter) that only the full partners and not associates should sign the exploitation agreement.

PR reported on discussions with the Ambrosiana, and formally proposed that the Ambrosiana be accepted as associate partners. This was accepted. He outlined the Ambrosiana’s plans for a complementary project to MASTER, addressing especially the following areas:

5. synchronization/harmonization of codicological vocabulary and authority files, to enable cross-language searching
6. translation of existing manuscript records held in databases into the MASTER format
7. extension of the standard to non-West European and to modern/documentary manuscripts

We agreed that these were excellent aims, and that we would continue to work with the Ambrosiana on these.

PR began by outlining the timetable. By 1^st September MASTER needed to have working software for input of manuscript descriptive records. The software development group (IRHT, DMU, OU) would need three clear months for the preparation of the software, which could not begin meaningfully until the standard itself had reached a settled draft. Such a draft would have to be ready by 1 June. Before that, the TEI workgroup had to consider the draft, and (especially) the Expert Group must study and comment on the draft.

PR therefore outlined the following timetable

1 March: the MASTER group, as a result of this meeting, declares requirements for first-level manuscript records for use in the first round of MASTER record implementation

15 March: the TEI workgroup meeting would consider the MASTER requirements in its preparation of a preliminary draft of the TEI standard, to take place in the Rome meeting of 5-7 March, and this draft should be submitted back to the MASTER partners (presumably in the form of a preliminary DTD and documentation)

30 March: the MASTER partners should have considered the TEI workgroup preliminary DTD, and extracted from this a working, preliminary DTD which should be both satisfactory for the needs of MASTER in the first cycle of record implementation and also conformant with the emerging TEI DTD

30 April: the Expert Group should have considered the MASTER preliminary draft standard, as determined by 30 March, and commented on this.

1 June: the MASTER partners should have considered the Expert Group standard and agreed the preliminary draft standard, for use in the first phase of record implementation. Software implementation can now commence

September: first software and record workshop, preparatory to first round of standard testing and implementation (to run from 1 October to 29 February 2000)

This is a demanding timetable. As a first step, this meeting had to determine a coherent set of software requirements for first level records.

PR then moved that LB, as leader of the standard development segment of the project, should take the chair for the discussion of this standard.

The group agreed that discussion should be based on the draft prepared in New York by Consuelo Dutschke, Merrilee Proffitt, and Peter Kidd (the ‘Claremont Conversations’). These conversations were themselves based on the agreement at the New York meeting of November 1997, itself drawing on earlier discussions at Studley Priory 1996 and others. There was general discussion on what was meant by ‘first level’ or ‘short’ records: at this stage, the group could only agree not to try (yet) to agree. After some discussion of interface and architectural issues, LB suggested that it would be fruitful and efficient if we concentrated on discussion of the intellectual content of each of the fields described in the Claremont Conversations, and deferred the issues of ‘first level’ requirement and architecture, etc., until we had an agreed and clear sense of the various parts of a manuscript descriptive record.

Accordingly, most of the rest of Friday (up to around 4.15) was taken up by detailed discussion of each field specified in the Claremont Conversations: what was its content? Its structure? Substructure? To what extent was its content unique to itself; how far might it overlap or be contained in other fields?

The following is mostly Merrilee Proffitt’s notes on this part of the discussion, edited by PR.

The manuscript identifier group of elements. LB questioned why have <country> <city> <region> and not <location>. Endless discussion on worthiness of <country> as an element. <country> defined as a modern political unit, <region> political subunit where appropriate, <institution> and <repository> deemed "easy". <idno>. MJD wanted to add format, and loan information. Format because it’s part of the shelfmark in the AM collection. Loan information because of the difference between loans and who owns manuscript, and to allow us to deal with things that are on permanent loan. This could go into <adminInfo> or <provenance>. <idNo> should be recorded either as previous or current: but elsewhere it was pointed out that previous shelfmarks should go into provenance. MJD asked: what to do about nicknames. Answer: deal with it later.

The text description group of elements: <span> span of folios (here, within a text). Discussion of <author> raised all the usual questions: how to deal with how author is recorded in mss vs. who we know the author is. Agreed that we should be able to use regularized form. DP: connected to issue of rubric, which is important in France (author name in rubric?). RG: we want <author> to be used for both (as above). <title> needs to be either modern or original, or both. <rubric> before the text, title and author, beginning sometimes with the word "incipit". Although it is pointed out that this is a special word in liturgical sense, in 15^th century Spanish text, it is clearly understood (whereas something like heading would not be) <incipit> important for identifying the text; <explicit>, <colophon>, <final rubric> all held to be important. MJD: in the case of a fragment, does the beginning and end of the text go into what we are calling <incipit> <explicit>? Answer: yes

The physical description group of elements: <format> codex, roll, or "broadside". Perhaps <form> would be a better word. <support> vellum or paper, material type. "Support of the manuscript rarely changes" MJD <extent> range of folios, here describing the entire manuscript, number of leaves. <dim> length, width, height leaf dimensions unless otherwise specified <layout> "two columns of 49 lines" ruled in lead, ruled in ink. Could have dimensions? <script> characterization of type of script. <scribe> who writing is ascribed to. Hand or an actual scribe. "written in three hands" vs. giving a name to that person. We might need something to put number of hands. PS: Needs also to tie to range of folios. <music> is it there or not, telling you what the manuscript looks like. Some people note it as part of layout. <damage> we want it, we should have it. Or <condition>/ At this point, LB (and PR) bring up the architectural point, which is that some of these elements are going to need to be included at other places. <decoration> same as with script above. Note its presence, say who did it (if you know) and describe it. <iconography>? This led to heated discussion: LB means specifically "the Virgin"; PS says this is going too far, and that one should use ‘Representational of something’ as a definition of iconography. Not there purely as ornament, additionally in paint or in pen. RG suggests maybe we should have decoration overview. PS: stressed that iconography, paint, penwork or none, form and technique all ned to be considered together. <artist> CWD/AK: assert that decoration needs to be tied to where it belongs in the text. <binding> same as with decoration, quite complication. LB asks how to deal with binding as part of provenance? Prose description of binding. <binder> is needed.

The history group of elements: <provenance>; <origins> where it was produced, dates; <ownership/provenance> who owned it, evidence, dates. Origins and provenance are distinct: EVERY manuscript must have one origin; but could have many provenances.

Other elements: <listBibl> bibliography for the manuscript, DiRicci etc; <source> sources consulted, source of information. Maybe these two can be rolled together under a <revisHist> type thing; <adminInfo> library management. "Dangerous information." Differences between European and American libraries. Collection management information. <altFormAvail> we need it -- but where does it belong?

MJD and others had a list of things excluded in the first round of discussion. These included:

MJD (and others) explained that the need for these was pressing, and so could not be deferred from the first level record.

Discussion now turned to issues of architecture. The first of these to be discussed was the question of composite manuscripts. LB (and PR) asked: why not just permit a whole description to contain any number of whole descriptions? CWD said: no, there should be only ONE MSID for a manuscript, and this should exist ONLY at the top level. Previous MSIds should be treated as aspects of the manuscripts history, and recorded in the provenance elements. This argument was accepted.

Discussion then turned to the matter of overall architecture. Is a manuscript description ‘metadata’ and so should be able to appear ONLY in the TEI header? Or, is it a textual object in its own right, and so able to appear only in the body of a TEI document? LB stated that several of the TEI specialists regarded manuscript descriptions as purely metadata, and so should be in the header. However, this view was contested very forcefully by CWD and other manuscript specialists: a manuscript description can itself be of the highest textual importance (often exceeding in interest the manuscript itself); they themselves can be catalogued and indexed, etc. LB accepted this, and said that the TEI implementation would support BOTH views: a manuscript description could live both in the header and in the body.

Discussion had, all through the day, been circling about the question of ‘first-level’ versus ‘full’ descriptions. It had become quite clear that any attempt to define ‘first-level’ in simple terms of a restricted repertoire of fields available to the cataloguer would fail. Beyond the basic agreement, that EVERY manuscript description MUST contain a ‘MSId’, it is not possible for any two cataloguers to agree that there are any fields, any aspect of any descripton, which is a priori dispensible of a priori necessary and sufficient.

However, as the day progressed, an alternative strategy began to suggest itself. As the separate fields were discussed, it became clear that discussion of (for example) the physical format of a manuscript could be extremely highly structured, into a highly-elaborate structure of fields -- or it could be simply a prose description -- or it could be a prose description, but with various phrase-level tags permittng recording of precise title or author formulae, etc. Thus, PS declared: she was interested only in searching on rare words, date, place, iconography, keywords, and that after that, reading the paragraph will unlock everything. CWD put this another way: who would ever want to search on a collation formula? RG suggested that at each level, the cataloguer might just choose to express information in paragraphs, only -- or use more elaborate structure if appropriate. PR and MP wondered if one should just not permit <p> elements anywhere within the structure, as a substitute/addendum to the more precisely defined tags. PR and LB harked with some longing back to ‘crystals’: selfcontained items of precise structure which could float anywhere within larger and loose bunches of text. Manuscript descriptions seem at times highly susceptible to crystalline formulation -- but not elsewhere.

At the end of the day, the group began to agree that the most effective distinction between ‘first level’ and ‘full’ records would NOT be made by defining what aspects of a manuscript could or could not be described in a first level record. We would never reach any such agreement. Rather, the distinction could be made in terms of the explicit complexity of the structure of the description itself. A ‘first level’ description might consist of no more than a prose description, structured in paragraph elements contained within the high-level containers. Thus this could be a first level description:

<physDesc>

</physDesc>

While this could be a ‘second level’ description of the same:

<physDesc>

</physDesc>

While this could be a yet more elaborate second level description

<physDesc>

</physDesc>

In discussion, the group began to see many advantages in this approach. Several times, it was stressed that ‘first level’ and ‘second level’ descriptions exist on a continuum: that different projects, different manuscripts, would need to define ‘first’ and ‘second’ levels differently. This architecture gives this continuum a most practical expression, as it allows exceptional freedom to individual cataloguers to use as much or as little additional structure as and where desired. It would permit making of extremely full and long ‘first level’ descriptions, where desired, and would offer an obvious ‘upgrade’ path by which such unstructured ‘first level’ descriptions could be enriched simply by additional tagging, without the need for gross rewriting of the record (a concern raised several times by Patricia Stirneymann). It would also guarantee compatibility between the various levels of description, and also greatly ease translation of legacy records into the standard: where these records had a structure which could be mapped onto the MASTER lower-level elements, then they would be translated accordingly; where there was no such structure, the generalized MASTER higher-level elements would act as containers for the data. In the most extreme case, for example, one could simply pour the whole description into the MASTER <shortdesc> element.

At this point, several of the group began to feel that they might, one day, see the grail, and LB declared that he felt himself liable soon to give birth to a DTD. Discussion finished at 5.45.

Overnight, LB had begun to calculate how the Friday conclusions could be transformed into a formal DTD. Here is the skeleton of this DTD:

Each manuscript description will be a single object. It may contain statements of

1. identification
2. physical description
3. intellectual content
4. history
5. other matter
6. part: a further manuscript description. This may contain all of the above EXCEPT manuscript identification

In practice most manuscripts will be a single object. A single manuscript part is defined as being of a single origin. A composite manuscript can be a single leaf of one origin, and 300 leaves of another origin. Such a description would treat this as a manuscript of two parts, with the common history of the two parts being described in the top-level <history> element

May contain the following

This element is mandatory, as are the City, Repository, and IdNo elements within it.

May contain the following, in any order:

Each <msbibl> may contain: PCDATA, author, title, respstatement, incipit, explicit, rubric, final rubric, ref, langusage, q, bibl., colophon, abstract (for dockets) all repeatable and in any order

The various <bibl> elements which can be contained within <msbibl> can be used to refer to editions, commentaries, any other information

<msbibl> May contain especially <ref target="…">Folios 1-12</ref> elements are used to point at the span of text. The <ref> element can be used to point at a range of pages, as transcripts or digital images. This was felt preferable to use of a separate <span> tag or expression of the span of text as an attribute on some other element.

It was felt necessary to construct a distinct <msbibl> element for this purpose so as to be able to permit it to have a distinct structure from existing TEI <bibl> elements. Thus, a <msbibl> may need to contain multiple <bibl> elements.

<langUsage> will be used within <msbibl> to document the language/languages of this part of the ms

May contain the following, in any order

<p>

and/or: the following elements

This is an excellent instance of the ‘first level’/’second level’ continuum determined at this meeting. The meeting was not able to detail further the possible structures available within the lower level tags in this group

May contain

May contain

Bibliography of the ms in <listBibl> elements

One matter unresolved: where does SecundoFolio go?

Discussion of the standard development concluded at 12.30 pm: over 24 hours since LB took the chair for this discussion.

This is a well-formed manuscript description!

<msdesc>

<msid>

</msdesc>

Here is the same manuscript, slightly more detailed:

<msdesc>

<MiscGarbage>

</msdesc>

EL and MG presented a software specification for the database work to be done by IRHT, for input of ‘first level’ records. This was discussed, with agreement that the suggested strategy and decision to use Microsoft Access as the database was sound. LB warned against reliance on Microsoft’s non-standard extensions to the SQL language. RG suggested that in this phase, as the database would clearly be appropriate and efficient for first level record entry, we put all software development effort into this, and defer the major effort of making SGML software till the second phase of record implementation, when we will be making second level records for which the database will NOT be adequate. The software group (OU DMU IRHT) will meet in Oxford in June to consider implementation.

PR reported that Ian Doyle had agreed to chair this group, and had nominated Gilbert Ouy as a second member. PR stated that in his opinion, the independent status of the Expert Group implied that once we had accepted Ian Doyle as Chair, we were bound to accept his nomination of other members: that is the meaning of independence. Conceivably, we might veto a nomination, but there did not seem any question of that. Accordingly, we accepted Ouy as the second member. Dr Doyle had also nominated Peter Gumbert, now of the University of Leiden, as a third member. Again, this nomination seemed very acceptable, and would give us an expert group of great authority and width of experience (exactly as desired).

PR outlined his understanding of how the expert group should proceed. We have to build into the timetable an opportunity for them to see and comment meaningfully on the preliminary draft standard. The suggested timetable (31 March: draft to be ready for their comment; 30 April: comments returned to the MASTER group) would permit this. It seemed important that we NOT simply give the group the draft and say: here you are. PR suggested that the group should be brought together for one day, that a member of the MASTER group should join the expert group on that day, and that the MASTER member would begin the day by briefing them on the background to the draft, explaining the reasoning behind key decisions (overall architecture, aims, context), and remain on hand to answer questions etc about the draft during the day. PR would be prepared to do this himself. Finally, the MASTER group is bound to consider the criticisms/comments of the expert group; we are NOT bound to accept them however. LB stressed the need for the MASTER group to provide appropriate material for the expert group: this led into a discussion on documentation of the developing standard; see below.

Since the meeting PR has spoken to Ian Doyle: the above is perfectly acceptable. Gumbert will be approached as the third member. The expert group will meet in April, and Doyle and PR will report on the exact place and time. Doyle suggested that it would help the group to have material to read in advance of the meeting and PR agreed this was desirable: see next section.

Though not an agenda item, significant discussion took place on this issue at different points of the meeting. It was agreed that careful and accessible documentation of the developing standard is crucial, as part of our drive to explain what we are doing to the rest of the manuscript community. There is a particular and pressing need to develop suitable documentation for the expert group. It was felt that concrete examples would help greatly in the development of such documentation. Therefore we agreed the following:

1. Following the Rome TEI meeting: LB will prepare a draft working paper, documenting the decisions made in Paris and Rome. This to be ready by 15 March.
2. On the basis of the draft: EACH partner will produce at least ONE example manuscript record, and send this to LB by 22 March.
3. The working draft is modified on the basis of the experience of making the example records, and may include some parts of these example records. This to be ready by 30 March.
4. Simultaneously with (3) above: PR prepares a more accessible and less technical account of the standard: its aims, strategy, content. This more accessible account will be the basis of the considerations of the expert group (who will also be given access to the formal draft itself). This also to be ready by 30 March.

Such a 'more accessible' account would obviously be very useful to us all, in explaining to others just what we are doing.

We agreed that our own ListServ would be a great help in carrying on these discussions. LB promised to set one up based at Oxford.

AK, who is leading this passage, had questions regarding what was required, and just what and who we should be concerting with. We decided to be rather narrower than was stated in the Project Plan, which spoke rather airily of various projects (MALIBU, CEDARS) which we decided really had very little to do with MASTER. We would rather have better information on a few projects which were REALLY relevant to MASTER than lots of patchy information about many projects which mean little to us. We will proceed by turning the MASTER 'links' web page into an annotated account of other initiatives in the area. AK will research this, and provide material to PR, who will have the web page updated accordingly. We also want other partners to provide such material: we will be asking you for this!

As we have developed a better understanding of what we are doing, we have a clearer sense of how the Associate Partners might fit into the MASTER world. We agreed that the first plan, of inviting associates to attend the first implementation workshop was sound. We agreed that we could not insist that associates contribute records made to the MASTER online catalogue. But we did agree that we could insist that associates must attempt to use the standard and must report on their findings. We should send all associates a letter to this effect. PR undertook to draft such a letter.

This is now better understood than at the previous meeting. Essentially, we agreed that the core responsibility of the MASTER group is to make a standard usable by the MASTER partners. The TEI workgroup has a wider responsibility, which cannot be expressed in terms only of making a standard usable only by a predefined group of users. Therefore, we could usefully think of the TEI standard as likely to be a superset of the MASTER standard. The timetable established for MASTER for the next six months keys with this understanding.

The next scheduled full meeting of all the partners will be the first implementation workshop, to be held in Prague 17-19 September. Part of this meeting will be a business meeting of the formal Project Consultative Committee. There could be a full meeting of all the partners preceding this if:

1. Discussions on the standard (eg by the TEI) bring up issues requiring a meeting to resolve
2. Or: it is felt necessary to have a meeting of the formal Project Consultative Committee before September. There are at present no specific agenda items for such a meeting (though some could arise, for example from the preparation of the Consortium Agreement)

We will monitor this by email, reserving the right to call such a full meeting if necessary.

There will be a meeting of the software development group (OU DMU IRHT) in Oxford on June 22-23.