.* TEI Document No: TDM1 .* Title: Minutes, TD meeting, Toronto, 5-6 June 1989 .* Drafted: Rich Giordano .* Wed, 12 Jul 89 16:30:03 EDT .* Richard Giordano .* Revised: .* .im gmlgdoc .sr docfile = &sysfnam. ;.sr docversion = 'Draft' .im teigml .* Document proper begins. <title>First Meeting of the Text Documentation Committee <title>University of Toronto <title>5-6 June 1989 <author>Rich Giordano <address>Princeton University <eaddress> <docnum>TEI &docfile. <date>&docdate. <etitlep> <efrontm> <body> Present: Bob Amsler (BA); Lou Burnard (LB); Marianne Gaunt (MG); Richard Giordano (RG); Hans Jø.rgen Marker (HM); Michael Sperberg-McQueen (MSM), Chair; Don Walker (DWa); Dominik Wujastyk (DW) <div1><head>Day 1</head> <p> Michael Sperberg-McQueen called the meeting to order, and provided the participants with the following guidelines and information: <list type="ordered"> <item n="1>We should have our recommendations completed by March, 1990. <item n="2">"Ease of use" section moved to the second portion of TEI- EDP1. <item n="3">Chair will send list of documents to participants and other relevant parties from Chicago. Most are available from the fileserver under TEI-L or TEI- DOC. <item n="4">Explanation of charge: we're involved with what might be called "the electronic title page." This brought on some discussion, which is sketched below: </list> <p> MSM: believes that this means to be able to make it possible for someone to identify the source text and the coding itself. There will be two layers: (1) physical "witness" of what is transcribed; (2) provision of information about the encoding itself. It's incumbent to make the distinction between the two clear to users. <p> MG: Wants to know where the codebook goes, and its function. <p> MSM: It goes in the header, with the analog being the standard study description form from Hans Jurgen Marker. Libraries don't have long descriptions, but data archives do. <p> JM: The data document publication (?) contains the SSD which describes the data. It (1) identifies the source; (2) identifies the encoding; (3) codebook/ssd/content description, including the relationship to the source document. <p> MSM: We can formalize the description so that they are analogous to declarations that are common to programming languages. The content of these "declarations" will be determined by the work of other TEI committees. Their work and the codebook should not be viewed as discrete. <p> MG: How do we complete our work in March when others are on-going? <p> MSM: Two ways: (1) keep alive some skeleton committee; (2) we can set-up a catch-all area for descriptions. <div2 type="section"><head>Plan of work.</head> <p> Because there is no dearth of how to do descriptives, our first steps should be the following: <list type="simple"> <item>(1) census: take a census of the kinds of information that people have found necessary for computer file description; <item>(2) merge: we'll have pieces of information that we can merge in some way; <item>(3) formalization: we can then set-up a formalized scheme using SGML tags. </list> <p> We should have the merger completed by October, 1989. <p> The committee agreed on surveying the following descriptive schemes: ISBD; ANSI Z39.29; AACR2 (chp. 9); SSD. Also mentioned were BibTex; Scribe; and troff- refer. <p> There was some discussion prompted by BA and DW on levels of description with DW saying we can have levels analogous to AACR2, and BA suggesting that there can be different instructions for different people. There should be a "minimal level" of encoding. <p> MSM: Suggests that there are processes to support. These include (1) library cataloging (by printing the header); (2) searching and access points for online catalog systems. This will be provided both by structured and free-text note fields; (3) data archive management; (4) application software; (5) pandita (??); (6) scholarship. <p> In summing up work to be done on a census, LB warned not to get buried in detail. <p> HM described SSD. The Data Document Publication includes (1) SSD; (2) Data Dictionary; (3) Questionnaire. 1 & 2 will always be machine-readable. SSD used as a basis for making printed catalogs; contains information useful for users; and as a basis for a retrieval system (in FDR it will even grab actual data). <p> RG discussed ISBD, and argued that it described a book in hand, and may not be wholly useful for describing encodings or computer-relevant information. It looks a lot like AACR2, and is really an international scheme. <p> There then ensued a discussion of putting tags at the top of a document. A sketch of it follows: <p> BA: If you have a list of tags, they should be put in a separate place. They should be considered a derivative object (my notes are unclear). <p> MSM: There should be a distinction between a list of possible values and the ones that occur. <p> BA: Then you run the risk of having a description that's longer than the object! Maybe there should be supplemental descriptions for a given community. <p> DW: Seems we're back to levels again. There should be different levels of description. For example, a person should have to say "I tagged for scansion," in a required field, but an optional field that says, in effect, "I used these tags," which themselves are a subset of tags from a full set. That can be something akin to a repeatable 500 note in MARC. <p> MSM: It should be possible to define a set of tags for a person who is not a cataloger to provide enough information for a cataloger to formalize it all properly. It may mean levels of description, but a minimal level will probably be undemanding for the person doing the description. <p> LB: Suggested that there should be a field called TAG_USAGE <p> Lou Burnard brought up the problem of copies of a transcript. He schematized the problem on a blackboard, and it appears in a slightly different form (to take into account the limitations of a computer screen). <eg> (1) (2) (3) SOURCE <-FEATURES OF SOURCE->TRANSCRIPT MRDF-> (see a) (4) a ENCODED MEDIA 1->ENCODED MEDIA 2->ENCODED MEDIA n </eg> <p> Problem is that ENCODED MEDIA 1 through n could be the same, or they could be different. LB argued, then, that we should focus our efforts on (1), (2), and (3). <p> Bob Amsler has a slightly different scheme. Again, it is described below: <eg> SOURCE<-->MRDF ENCODING-->MRDF MEDIUM->computer1-> computer 2->computer n </eg> <list type="ordered"> <item n="1">Bibliographic information points you to the source. <item n="2">From source to MRDF ENCODING, describe how the text is captured <item n="3">From MRDF ENCODING to MRDF MEDIUM, describe computer- relevant information, for instance information to tell you what sort of tape is being used. <item n="4">From MRDF MEDIUM to computer n, there should be some command to make sure that data are read properly. </list> <p> BA wants to ensure that 3 is not mixed in with 1+2. <p> LB: expressed a sentiment that we should find ways of including 3. (?? notes unclear). He suggested that we put 3 in document header. <p> MSM: put it in data archive documentation. Consensus reached on this point. <p> <div1><head>Day 2.</head> <p> Present: Bob Amsler; Richard Giordano; Marianne Gaunt; Hans Joergen Marker; Michael Sperberg-McQueen. <div2><head>AACR2</head> <p> Mary Gaunt described AACR2. It's a lot like ISBD rules. Idea is to describe uniquely each item. MARC is derived from AACR2 in that for each AACR2 "area" there is a corresponding MARC field into which librarians stuff bibliographic information. <p> MSB: Raises the question of whether there should be a unique number, such as a MRDF ISBN, for data files. <p> HM: Doesn't see a MRDF ISBN as something feasible. ISBN are assigned by large publishers. What would you do with files outside of large data archives? If there were some parallel to SS Data Archives all over the world, you might be able to do it. If there are central institutions that care for MRDF, you may get a number attached. At the moment, such institutions do not exist. <p> MSM: We should suggest that "sponsoring organizations" should be aware of this "ISBN" consideration as a possible future issue. The group agreed on this point. <p> After MG finished her description of AACR2, MSM suggested that we should have as one goal a header for the "principal source of information" for a cataloger to use. <p> MG: Sees two problems: (1) presently a lack of information for a cataloger to put into a cataloging record; (2) what information should go into a description technical file characteristics. <p> The group discussed the 538 note, but agreed that technical characteristics are not fixed, and this in itself poses a problem related to its usefulness. <p> MSM: then presented an SGML exercise for a true MARC record. He broke the description into two segments: a segment for the source, and a segment for a machine-readable file. <div3 type="subsection"><head>SEGMENT FOR THE SOURCE</head> <eg> <![ CDATA [ <copytext> *<form> printed monograph <title> septuaginta, id est vetus... <resp><name>Alfred Ross<\> <role> ed.<\><\> <publication><place> Stuttgart <publisher>Wurtembergsche Biberlanstait</> <date>1935, [1971]</date> <physical description> <series> <notes> <std_num> ]]> </eg> <div3><head>SEGMENT FOR THE MACHINE-READABLE FILE <MRDF></head> <![ CDATA [ <title>Septuagent <resp><name>Thesaurus Linguae Graecae <role> compiled by <name>Center for CAT <role> Sponsor </de></resp> <file_characteristics> 1 data file <publication><place>Philadelphia <publisher> CCAT <date> 1987 <avail><contact> Robert Kraft <address>... <misc> dist. on 15 diskettes <series> <notes> With Biblia Hebraica Stuttgartensis, the Greek NT, The Holy Bible RSV <std_num> ]]> </eg> <p> (SGML is the syntactic basis of the encoding scheme TEI is developing. (ISO 8879). Despite its name, it's not a markup language, but a metalanguage, and it's an international standard.) <p> In the parallel segments assume that there is data for all the fields. <p> <div1><head>THINGS TO DO:</head> <p> 1. A census of features that are relevant. We should come up with a fine grouping, probably a little finer than what we'll actually use. Then we'll add the features that the present coding doesn't allow. <p> We should take a scheme and make a database from it, and EMAIL or databases to MSB who will post them back to the group. <p> Discussion ended with these questions and concerns: <p> HM: there's a problem with layer dates from the source. Take the bible in the example above. How did it get to this 1971 edition? That dates from the source to the present edition are very important, and we should include them. <p> RA: the role of the copytext is the information important to the who made the MRDF. SOme people may be interested in the origin of the object, but most people aren't interested in its provenance. <p> MSM: <list type="simple"> <item>when making the database and thinking of the parallel segments, keep librarians in mind, but worry about the generalities of interest to historians. <item>think of practical matters and take real examples. Make up an example as we did above. We can do this electronically. <item>we should think of merging the tags into a structure <item>we can think of a concordance to what's known </list> <p> We should spend the first part of the summer on the census, and each of us should provide MSB with a number of examples. <p> PREPARED BY RICHARD GIORDANO <p> 12 JULY 1989 </body> </text> </tei.2>
http://www.tei-c.org/Vault/TD/tdm01.gml
www.tei-c.org
crawl=CC-MAIN-2018-34
12424
application/http; msgtype=response
sha1:DVW5XN6IEDVRJCHL3MWNMIYRHHCDZWDZ
<urn:uuid:71643a89-3d1d-454a-a530-2c1fb1d2231e>
2018-08-17T01:17:01Z
87.106.166.188
text/plain
sha1:NU3KNLAPHW34BMONXZ5A2JAFDFVUM4VT
<urn:uuid:df9ffd5d-bf24-4919-9601-1fcfd2468135>
http://www.tei-c.org/Vault/TD/tdm01.gml
response
<urn:uuid:0505820e-3ebd-40d3-9f04-a21caa864683>
isPartOf: CC-MAIN-2018-34
publisher: Common Crawl
description: Wide crawl of the web for August 2018
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-61-240-216.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 0.11-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/