Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.1] Revision[1.1] Date[11/28/99]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ TEXTBOOK ]
Entity Type
Independent_Entity[ x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
This entity exists in the form created by Allan Kohl and is fully populated with data as a MS Access file. [Rev 1.1: Fields have been added to some of the entities that constitute the Kohl schema.]
The Textbook entity comes from Allan Kohl's Concordance database. It is used to register the bibliographic citation of textbooks that have been indexed to form the "concordance core" of the AIC database. In turn this entity is linked to the PLATE entity that records the textbook plate/figure numbers for each textbook.
This entity should be turned into (or merged with) the Bibliography entity and the textbook citations should be included in the Bibliography [entity] as a subset. A single byte logical (boolean) field in this Textbook/Bibliography entity called "CoreText" identifies those editions that are indexed for the concordance.
[The Concordance is an image-by-image index of all illustrations in s set of designated textbooks. The "concordance set of images" are all those images in the AIC collection that correspond to images appearing in the concordance set.]
The fields in such a Bibliography entity should accomodate journal articles as well as books. (See further, comments on the wide-ranging use of the Bibliography entity.) Suggest building BIBLIOGRAPHY as a Generalized Hierarchy with BOOKS and SERIALS (and possibly other resources), maybe as hierarchical subtypes.
[The ideal is to build a bibliographic entity that mirrors the functionality of the application "EndNote." Until then -- a goal to be set aside for the development of the "Prototype" system -- all other ocurrances of the "Bibliography" entity will simply have a longish text field in which to render items according to a to-be-specified bibliographic stylesheet.]
BIBLIOGRAPHY can be linked to other entities as need requires. For example in an instance of an ATTRIBUTION it may be required to link ATTRIBUTION to an instance of BIBLIOGRAPHY and supplying locally to ATTRIBUTION to specific citation or reference within the BIBLIOGRAPHY record cited.
BIBLIOGRAPHY [TEXTBOOK] must contain a field that identifies any records as belonging to the set of texts designated as part of the "concordance core" texts.
Structure:
Textbook entity is a parent of PLATE
One TEXTBOOK to many PLATEs
TEXTBOOK must exist before PLATE
PRIMARY KEY is TextbookID
Linked to FOREIGN KEY in PLATE called TextbookID
TEXTBOOK is parent of TEXTCHAPTERHEAD
One TEXTBOOK to many TEXTCHAPTERHEADs
TEXTBOOK must exist before TEXTCHAPTERHEAD
Linked to FOREIGN KEY in TEXTCHAPTERHEAD called TextbookID
A Textbook record cannot be deleted if records in the Plate entity are linked to it.
FIELDS:
TextbookID
TextbookID is the primary key for the Textbook entity. Values are assigned serially and are retired when a record is deleted.
Descriptor
Descriptor is a shorthand text abbreviation for the text and edition. Janson5 might indicate that the book is Janson's History of Art, 5th edition. Each value in descriptor must be unique. It is assumed that the image content and the image figuration in any single edition is uniform.
Title
Title is the official Title of the textbook as would be recorded by a librarian.
Edition
Edition is the edition of the textbook being indexed. It is not the printing number, but signifies that this edition differs in plate and figure content or pagination from another edition.
Publisher
Publisher is the name of the company or imprint or distributor that has published or brought to book to press. It is rendered as appropriate for library purposes. Note, publishers and publisher names may change during the publication history of a book. The field "publisher" records the name of the publisher as is found in the edition being indexed. [Note: It may be useful to record publishers in the "Corporation" entity.]
PlaceOfPublication
This is the city (usually sufficient) or city and district where the textbook was published. Entered in accordance with library cataloging rules.
YearOfPublication
The four digit representation of the publication year. In general, the year of first printing is appropriate, not the year of the printing in hand. [If complex printing projects are eventually included in the "concordance" data-set, it may be necessary to change YearOfPublication into two fields: one designating starting year of publication and another designating end of publishing cycle.]
CoreText
Because the Textbook file will eventually be merged into a bibliography file, the boolean CoreText field permits the editor to indicate which texts in the bibliography have been indexed [for the Concordance].
Hypothetical
On of the features of the Concordance device is to categorize images by their chapter headings in the textbooks [see TextChapterHead]. This will permit any user to request all images that appear in, for instance, Janson's discussion of "The Renaissance of the North." This device, useful for working with textbooks, however, will omit many works from being included in a cataloging scheme. We therefore define [one or more] hypothetical textbook[s] that [may] include all images used in all the indexed textbooks and invent chapter heads that will bring all [concordance and other] works into their appropriate place. This field identifies those structures, entered into the bibliography, that are not publications but which do arrange the set of images.
We propose that over the years there will be several alternate arrangements proposed and it might even become a student or class project to create new arrangements. When the AIC(formerly AIE) records these structures, they will be placed in the concordance, documented in the bibliography entity, and their divisions and sub-divisions will be recorded just like textbooks. But they will be marked as "hypothetical."
]
Entity_Connection_One-Name[ PLATE ]
Entity_Connection_One_Cardinality[ 1:M] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ PARENT of PLATE ]
Manditory[ x] or
Optional[ ]
Entity_Connection_Two-Name[ TEXTCHAPTERHEAD ]
Entity_Connection_Two_Cardinality[ 1:M] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_Two_Direction[ PARENT of TEXTCHAPTERHEAD]
Manditory[ x] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.2]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ PLATE ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ Y] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The PLATE entity exists in the form created by Allan Kohl and is fully populated with data as a MS Access file.
Every instance of PLATE is dependent upon an instance in TEXTBOOK. It records each instance of an illustration in the textbook and records the textbook identification (TextbookID) and the plate number. It does go so far as to identify any of the plates and it is impossible to determine on the basis of the records in this entity which illustrations represent the same work or object.
Structure and Rules:
1.PLATE is child of TEXTBOOK
2.PLATE links to PLATETOWORKASSOCIATION through PlateID in a one-to-many relation to cover the possibility that one plate (or illustration) in a textbook can illustrate more than one work as catalogued in WORK. Thus, by choosing a plate record in PLATE it should be possible to link to all works in the database that show that work.
3.[Delete: There is an optional one-to-one link between PLATE and records in TEXTCHAPTERHEAD. From any plate one should be able to enter the TEXTCHAPTERHEAD hierarchy (first choose a textbook) and then query the chapter headings hierarchy to broaden and narrow one's focus. See additional details in discussion of TEXTCHAPTERHEAD entity.]
FIELDS:
PlateID
The primary key for the Plate entity. Values are assigned serially and are retired when or if a record is deleted. (Kohl Concordance Field)
PlateNumber
The PlateNumber is the representation used in the textbook to identify the plate or figure or illustration. When such numbers do not exist the page number can be used as a substitute [making certain to supply a suffix to distinguish images residing on the same page]. Because the PlateID field uniquely identifies each record it is not necessary for the PlateNumber value [recorded] for any single textbook be unique.
There is a problem, however, in the use of PlateNumber when used in queries. It will be difficult to query for a range of values using plate numbers. Textbooks frequently will mix several system for referring to illustrations. There may be "plates," "figures" pages only, among other devices. While it is important to refer to images precisely as they were cited in a textbook, another means of citing image location is needed. (Field from Allan Kohl's database.) [The use of the TextChapterHead recursive query device helps get around this problem. Another way to solve it is to request that all queries for plate number be issued as numerical values only and that the PlateNumber field be searched for a numerical string that corresponds to the request.]
PageNumber
PageNumber is the number of the page on which an illustration appears. preliminary pages with illustrations should be entered as negative numbers (excluding zero). Illustrations appearing between consecutive pages should be identified in decimal form. For example images after page 256 and before page 257 might be 256.1, 256.2, etc. This will insure that they appear in a range search.
I've designated the datatype to be a "single" but this will introduce problems for non-numeric numbering schemes. It may have to be changed.
[Following is all additional text.]
TextChapterID
This is a foreign key that links records in the TextChapterHead entity to the Plate entity. Any single plate may be linked to one or many records in TextChapterHead. Typically they will be linked to the record that designates the smallest division catalogued. All records in Plate must be linked to at least one record in TextChapterHead, while not all records in TextChapterHead (those records for higher level hierarchies) need be linked to records in Plate.
TextbookID/1
TextbookID
These two fields come from the Textbook and TextChapterHead entities respectively. They serve as foreign keys that may be used in the first instance to bring up the record for the related textbook for any record in the Plate entity and in the second instance to bring up all records in TextChapterHead (through the Textbook entity) that are linked to any single Textbook.
]
Entity_Connection_One-Name[ TEXTBOOK ]
Entity_Connection_One_Cardinality[M:1] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ Child ] Parent / Child
Manditory[ x ] or
Optional[ ]
Entity_Connection_Two-Name[ PLATETOWORKASSOCIATION ]
Entity_Connection_Two_Cardinality[1:M] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_Two_Direction[ Parent ] Parent / Child
Manditory[ x ] or
Optional[ ]
Entity_Connection_Three-Name[ TEXTCHAPTERHEAD ]
Entity_Connection_Three_Cardinality[1:1 optional] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_Three_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ x ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.3]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ PLATETOWORKASSOCIATION ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ ] or
Associative_Entity[ x] or
Subset_Entity[ ]
Entity_Description[ -
This entity [is based on the example] created by Allan Kohl and may be populated with data from his MS Access file.
[PlateToWorkAssociation connects three entities. From Allan Kohl's model the Work entity is connected through PlateToWorkAssociation to the Plate entity. In addition, with the integration of the full model based on the VRA core categories (ver. 2.0) the WorkItem entity is linked thorugh PlateToWorkAssociation to the Work entity and to the Plate entity.]
Structure and Rules:
1.PLATETOWORKASSOCIATION links instances of PLATE to instances of WORK. Any single PLATE can (through PLATETOWORKASSOCIATION) link to any number of WORKs. Any single WORK can link to any number of PLATETOWORKASSOCIATION records which then each connect to one instance of PLATE. A query on a single work should lead to the books and plates that illustrate that work.
2.In the Concordance Diagram WorkItem is represented in a summary fashion, without its detail of relationships. WorkItem entity holds the same relationship to PlateToWorkAssociation as the Work entity does:
FIELDS:
PlateID
PlateID serves as the foreign key connected to the entity Plate.
WorkID
WorkID serves as the foreign key connected to the entity Work.
WorkItemID
WorkItemID serves as the foreign key connected to the entity workItem.
PlateDepictsWork
The Boolean Field PlateDepictsWork (inherited from the Kohl Concordance files) signifies the assignment of a plate to a work that is substantially similar but not the same work that appears in the textbooks. If PlateDepictsWork is affirmative (Y or True or checked) then the exact work cited in the textbooks is represented in the WORK record. If it is negative, then the work cited in the textbook has not been described in the WORK file, but a similar example pedagogically equivalent has been substituted.
I would recommend that a list of plates from each textbook that are identified by a negative value in PlateDepictsWork field be produced and that records for these items be entered into the WorkItem file of the database. When PlateDepictsWork is negative, the link to WORK records should be made from the WorkItem record to the image file of the substitute work and identified as a substitute. In this way we will have a list of works for which we have no images.
Allan supposed that for certain works there might not be images and because these works were substantially the same as other works for which images might be available, he created the association. But in the future, images for the "associated" works (called "consensus" works) might be obtained. In my opinion I believe it is better to have a catalogue record for all works that appear in the textbooks and to link that record to the catalogue record of the "consensus" work and from there go to the image. The link can be something like "see functional equivalent" or "see also."
TextChapterHeadID
This field is an artifact of VISIO. It indicates that any record in the PlateToWorkAssociation entity may be linked to an associated record in TextChapterHead through the Plate entity.
TextbookID/1
TextbookID
Similarly, links from PlateToWorkAssociation to the Textbook file are possible through the Plate entity and through the TextChapterHead entity.
]
Entity_Connection_One-Name[ ]
Entity_Connection_One_Cardinality[ ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.4]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ TEXTCHAPTERHEAD ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ]? or
Associative_Entity[ x ]? or
Subset_Entity[ ]
Entity_Description[ -
NOTE: Need advice on construction of this entity.
[Delete: TEXTCHAPTERHEAD is not fully diagramed in the VISIO plan.
The purpose of TextChapterHead is to record hierarchically the text chapters used in each of the core textbooks, and to use that hierarchy to create searches within the chapter hierarchy of any one textbook. These searches may end [with links to] a set of records (or a single record) in the PLATES entity (file). Other hierarchical searches are also possible.
For any single textbook listed in TEXTBOOK (BIBLIOGRAPHY) there will be a set of records in TEXTCHAPTERHEAD. Each such record contains two main fields for content: a "Broader Division" and a "Narrower Division." For every "Broader Division" a new record identifies each of the "Narrower Divisions" as a field under the stated Broader Division. Thus they appears in pairs. Correspondingly each named "Narrower Division" can be a broader division to a set of yet narrower divisions.
[Delete: This hierarchy is filled until the narrowest text division is placed into the broader division category and its narrower division is a Plate (the same as the PlateNumber field in PLATES. (See comments below on merging the PLATE entity and this TEXTCHAPTERHEAD entity.)]
[This hierarchy is filled until the narrowest text division is placed into the broader division category and its narrower division is empty. Each record with an empty narrower division field signifies the end of a hierarchical set. Each such record must be linked to a record in the PLATE entity in a one-to-many relationship. Each qualifying record in TextChapterHead may be linked to one or many records in the Plate entity.]
[Delete: Only when the narrowest division recorded is a PlateNumber, the PlateID field is filled to link to PlateID in PLATE. This link is optional based on a record in TEXTCHAPTERHEAD pointing to a plate. The set of narrower division fields when combined with the originating textbook produce a unique set of values.]
The PlateID in PLATE must precede the existence of PlateID in TEXTCHAPTERHEAD.
Recursive Relation:
The TextChapterHead entity contains a recursive relationship that connects Broader to Narrower attributes (fields). The field TextChapterID identifies the broader field (BroaderDivision) and the field TextChapterID/1 is set equal to the TextChapterID of the record where the NarrowerDivision field is represented as a value in a BroaderDivision field. Because each value in a NarrowerDivision field must be unique within any one textbook, there is a one-to-many recursive relationship between a NarrowerDivision field and the records where that NarrowerDivision field hold the location of a BroaderDivision field.
Conversely there is a many-to-one relationship from a number of records where the BroaderDivision field value are equal to each other (within the same textbook) to the single record where the value in the BroaderDivision field is equivalent to the one record in which the BroaderDivision value is equal to a NarrowerDivision value.
Rules:
The builder of recursive relationships should be prevented from creating circular structures in which parent records are made children of their own children or descendants.
NOTES ON USE:
The TEXTCHAPTERHEAD entity is defined in order to provide a text-specific and alternate means of querying the WORK [and eventually the WorkItem] dataset. Instead of queries by a specific object or some conventionalized rendition of art historical divisions, the textbook structure is taken as the primary means of access. This provides features of special use to students and teachers. It also has considerable potential to document the evolution of pedagogy. Further, if carried out systematically, the concordance system may have significant ramification for the indexing of bibliography of works of art.
This file uses a Recursive Relationship in which 1) a query from a broader division into a narrower division finds all records in which that broader division also exists as a narrower division, and 2) a query into a broader division finds all records in which that broader division contains narrower divisions.
Functional Requirement [for queries that begin with the TextChapterHead entity]: A query mechanism must be defined to allow the user first to select a textbook. This will bring up a display of the primary chapters. The user chooses a chapter and receives a display of the secondary divisions under that chapter, choosing a secondary division brings up the tertiary divisions under that, and so on until all the set of records constituting the plates associated with the bottom-most division have been selected. These final records then [link to] the PLATE file (or the same: the PLATETOWORKASSOCIATION file) which leads to the set of WORKs.
Alternately, the user must be allowed to stop the process of searching for hierarchically defined divisions without having reached the bottom set, and be allowed to ask for all works that exist under the current heading -- a broader head -- including all those works that exist under the full set of narrower heads. In that case, the query mechanism searches down all paths for all records [in the TextChapterHead entity] below the current head and all records under that until all lowest-level records under the current division have been identified. These are passed to the PLATETOWORKASSOCIATION file and then to the WORK file.
The user should be able to work these queries in the opposite division. Starting with a WORK record [or a qualifying WorkItem record], querying the PLATETOWORKASSOCIATION the user obtains a set of PlateID that lead to all the textbooks containing that PlateID. At that point the user must choose a single textbook and be given the narrowest division (or divisions if the plate is used more than once in the textbook) in the text. From the narrowest division the user can query up the hierarchy or down as he pleases, working as described above. Starting with a low item in the hierarchy the search automatically move upwards until the single set of steps leading to the name of the book has been produced. The name of the book should be taken from the TEXTBOOK file through a lookup that uses the "Descriptor" field (the book shorthand name)(or the TextbookID -- BibliographyID in its evolved manifestation).
[To prevent any such query from including more images or more works than the user wishes to access, the user should be able to specify a maximum number of records to report at a time.]
The two Boolean field: "Broader Is Top" and "Bottom is Plate" help the query mechanism identify when to stop searching in either direction. When the "Bottom is Plate" is "Y" then the TEXTCHAPTERHEAD record can link to the PLATE or the PlateToWorkAssociation entity.
Notes:
Note on Kohl's hierarchical divisions as created in the four entities "DisplayCategory," "PrimaryDivision," "SecondaryDivision," and "TertiaryDivision."
These divisions are temporary, they are assigned a hierarchical purpose but are not hierarchically structured [beyond three levels]. It is possible to mix and match the divisions in non-historical manners. The nomenclature and structure intended by these mechanism must be re-written into the TEXTCHAPTERHEAD hierarchical syntax, but because they do not derive from any single book, they must be assigned to a hypothetical record in the bibliography (Textbook) entity. Because it is conceivable that more than one such hypothetical record with its associated taxonomy of works in the future may exist, the hypothetical record must be given a unique name and/or TextbookID. A Boolean field in TEXTBOOK named "Hypothetical" identifies the class of these structures.
NOTE: It may be possible to combine the TEXTCHAPTERHEAD and PLATE entities.
Structure:
PRIMARY KEY: TextChapterID is linked to instances of TextChapterID/1 which serves as a recursive Foreign Key.
FOREIGN KEY: TextbookID links to TextbookID in TEXTBOOK.
FOREIGN KEY: PlateID links to PlateID in PLATE and/or to PlateID in PLATETOWORKASSOCIATION.
One TEXTBOOK to many TEXTCHAPTERHEAD records
All records in PLATE will link to records in TEXTCHAPTERHEAD, but only
some records in TEXTCHAPTERHEAD will link to PLATE.
All records in PlateToWorkAssociation will link to records in TEXTCHAPTERHEAD, but only some records in TEXTCHAPTERHEAD will link to PlateToWorkAssociation. [Delete: The link when it exists, is one-to-one.]
Value in "Narrower Division" will only appear once in a narrower division record. The value in a "Broader Division" field may appear more than once in a broader division field. The value in a "Broader Division" field may may appear in a "Narrower Division" field.
It is possible to normalize the TEXTCHAPTERHEAD files by using an authority file for the names of the chapter divisions(with a lookup to the textbook name), but I don't think the effort is worth it considering the relatively small size of the TEXTCHAPTERHEAD file or the small number of records per textbook.
FIELDS:
TextChapterID
This is the primary key field for the TextChapter entity. Its values are unique and are assigned sequentially. [TextChapterHeadID may be found as Foreign Keys in PlateToWorkAssociation and in Plate.]
TextbookID
This is the foreign key that links the Textbook (later Bibliography) entity to the TextChapterHead entity. One record in Textbook links to one or more records in TextChapterHead. For each of the designated "Concordance Core" textbooks there will be a link into the TextChapterHead entity. When the Textbook entity is turned into the Bibliography entity, only some records in the Bibliography will be linked to records in TextChapterHead.
BroaderDivision
This field holds the name of broader division chapters or subchapters.
NarrowerDivision
This field holds the name of narrower division chapters or subchapters.
In any single record in the TextChapterHead entity there may be listed a BroaderDivision title and a NarrowerDivision title.
BroaderIsTop
This boolean field indicates (when True) that the current record is the highest level record in the hierarchy. It is used for automatic creation of hierarchical lists when the query begins from a lower level and works its way upward. The process works something like the following:
1)From any NarrowerDivision value in a lower-level record in a TextChapterHead record (noun), record (verb) the value of the NarrowDivision field and its corresponding BroaderDivision value.
2)If the value of BroaderIsTop is False, then search for a record in which the current TextChapterID/1 is equivalent to a TextChapterID field. This finds the single record where the current BroaderDivision value is located in a NarrowerDivision field. Record the BroaderDivision value.
3)If the value of the new current BroaderIsTop is False, then search for a record in which the new current TextChapterID/1 is equivalent to a TextChapterID field. This finds the single record where the current BoraderDivision value is located in a NarrowerDivision field. Record the BroaderDivision value.
4)Continue this process until the BroaderIsTop value is True. Recording the value of the last found BroaderDivision field.
5)Display a list of all the BroaderDivision values in reverse order (with last found on top) and on the bottom the value of the NarrowerDivision field from which the query set began.
6)The list is active and is used to query the TextChapterHead entity at any of the listed levels. For example, if a hierarchical display (we'll call it the "Upward" hierarchy produces a list of values in this order:
A, 2, c, 6'
(The hierarchy follow this form: A, 1, a, 1', a', 1", a" etc.)
the user can choose any level, say level 2 to query the database and discover that there are (say) two sublevels directly under 2: c and d.
The point of this query is to find all the works associated with any given level. So the user may choose any currently displayed level and ask for a list of all works classified in that level and any level beneath it. For example had a user chosen to see all works under level 2 the query engine will follow all subpaths until it reached the end (where field NarrowerIsPlate is True) and ended up with a list of values for PlateID that ultimately links to WorkID or to WorkItemID.
Or the user can choose to move down a level in the hierarchy by choosing to pass to a lower level. Using the example above, after noting that the two sublevels of level 2 are c and d, the user can choose c and in this "Downward" query will discover that under level c are levels 5' and 6'. Moving on in this hypothetical example, by choosing level 6' the user may find that he has hit bottom and now has a list of works to view created by links at the bottom of the chain that connect [subsequently] to the temporary Work entity or to the permanent WorkItem entity.
NarrowerIsPlate
This field indicates that the bottom of a hierarchical structure of subchapters and sections has been reached and that there is no value in the NarrowerDivision field. Correspondingly the foreign key field PlateID now does have a value. See discussion above to see how this works. When a query is working in a "Downward" direction the current TextChapterID is used to query the TextChapterID/1 field, where a one-to-many relation exists: one instance of TextChapterID to one or more instances of TextChapterID/1.
This field is redundant. The same information can be obtained by inspecting the contents of the NarrowerDivision field and the PlateID foreign key field, as discussed above.
PlateID
This is the foreign key that links some of the records in the TextChapterHead entity to the PlateID field in the entity Plate (where one record will be found) or the PlateID field in the PlateToWorkAssociation entity where one or many instances may be found.
TextChapterID/1
This is the recursive foreign key corresponding to TextChapterID in the TextChapterHead entity. There may be multiple instances of values in TextChapterID/1, each of which point to a record in which the current BroaderDivision value holds the place of a NarrowerDivision value.
TextbookID/1
This recursive foreign key is an artifact of VISIO, which placed it automatically. As far as I can tell it has no meaning since the TextbookID field already points to the Textbook (later Bibliography) entity and there is no reason to have a second recursive structure here.*
]
Entity_Connection_One-Name[ TEXTBOOK ]
Entity_Connection_One_Cardinality[1:M ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ x] or
Optional[ ]
Entity_Connection_One-Name[ PLATE ]
Entity_Connection_One_Cardinality[1:1 ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ x] or
Optional[ ]
Entity_Connection_One-Name[ TEXTCHAPTERHEAD ] (recursive)
Entity_Connection_One_Cardinality[1:M ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ parent ] Parent / Child
Manditory[ ] or
Optional[ x ]?
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.5]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ WORK ]
Entity Type
Independent_Entity[ x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
This entity exists in the form created by Allan Kohl and is fully populated with data as a MS Access file.
The WORK entity is a temporary file constructed by Allan Kohl to provide a quick identification for the objects catalogued in the Concordance. The term-authorities in this file are not necessarily valid for the AIC. The field structure does not correspond to the VRA Core and cannot be used as an object catalogue.
However data from the WORK file can be mapped into the approximately corresponding fields in the VRA core entities as long as they are marked as provisional and subject to editing. This will make the task of the cataloguers simpler.
Structure:
One WORK instance can be linked to more than one PLATETOWORKASSOCIATION instances.
WORK is Parent of PLATETOWORKASSOCIATION.
For the time being each WORK must be linked to at least one record in PLATETOWORKASSOCIATION. This is because each record in work represents an image in a textbook or is the functional equivalent of an image in a textbook. In the WorkItem entity, however, there will be more works catalogued than appear in the concordance. In that case there will only be an OPTIONAL link from the WORKITEM to the PLATETOWORKASSOCIATION.
For those records in the WorkItem entity, some may be linked to records in the PlateToWorkAssociation entity. Of those records in the WorkItem entity those that are linked may be linked to more than one record in the PlateToWorkAssociation entity.
In any case, the WORK record (or the WorkItem record) must pre-exist the PLATETOWORKASSOCIATION record. If a record in WorkItem (or Work) is to be deleted, the linking record in PlateToWorkAssociation must be deleted first.
FIELDS:
All of the fields in this entity are designed as single-value fields.
WorkID
This is the primary key field of the Work entity. Each record in Work is assigned a new number sequentially. No duplicates. Values for deleted records are retired.
CulturePeriodStylePeriod
Kohl: "a combination of the culture, people, and style period that producted the work." This classification is an approximation of the VRA Core (V 2.0) classification W.14: Style/Period/Group/Movement. The values entered into this classification have not been vetted by the AIC cataloging committee. For works created in the Renaissance and Post-Renaissance periods this field reverts to the name of a country -- typically a country that currently exists.
Creator
The Creator field for anonymous works reverts to the values placed in the CulturePeriodStylePeriod field. For works of known makers name appear in a form that has no discernable syntactical rules. These values cannot be used for queries or for final cataloging, but they are useful and may be mapped to the Creator VRA core category as long as that category is marked as having unproofed data in it.
Title
The title data in this field includes subject descriptions, titles, locations and descriptions of views. The data may be mapped to the Title category and marked with a title type as "provisional."
Date
The format of the work date field is narrative and for display. It is not formatted for queries.
Medium
Medium corresponds approximately to the VRA Core (v. 2.0) Materials entity. It also incorporates terms more rightly placed in a techniques entity such as defined for the VRA Core (W.5.).
Dimensions
Dimensions, corresponding to the VRA core Measurements entity (W.3) is a single-value field that records measurements in a formatted narrative manner approximately suitable for the field MeasurementsDisplay that appears in the WorkItem entity in the AIC Subjects Entity diagram.
RepositoryName
In the Kohl concordance database Repository name is defined as "the current (or last known) location of the work." In this manner RepositoryName fuses several VRA Core entities: W.9: Repository Name, W.10: Repository Place, W.12: Current Site, W.13: Original Site.
ChronologyIndex
A numerical field said to be used to sort records by chronology (i.e. chronologically). This seems not to have been implemented in the Kohl Database. All values equal zero.
]
Entity_Connection_One-Name[ PLATETOWORKASSOCIATION ]
Entity_Connection_One_Cardinality[1:M ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.6]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ ImageDonorCheckList ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
ImageDonorCheckList is a temporary file used to assemble the list of works that are to be supplied by our internal set of image donors. the data in it can form the basis of the Image Sources Entity, the Image Data Entity, and Views Entity. (See Entity relation diagram.)
In the fully implemented AIC system, as described in the entity relationship diagram, image contributors are recorded in an "Image Sources" file. This file is linked to an "Image data" file that contains specific information about the image submitted. This file is directly linked to images and to a description of the view that the specific image portrays. The "Views" file, finally, is linked to a description of the Work.
For the purposes of constructing a quick Want List, however, we are going to take a shortcut. The ImageDonorCheckList entity offers image donors an opportunity to indicate that they have images related to the works depicted in textbooks.
Each donor in his or her personal copy fills in none, one or more records in ImageDonorCheckList per work cited in the work file, corresponding to their records (or memory) of what they have.
Using the Concordance database (specifically the Work entity) as prepared by Allan Kohl as the basis, the ImageDonorCheckList table is added. The database is then copied and distributed to our key internal donors. Each Donor then pages through the works file or queries individual works, and fills out the linked form created for the ImageDonorCheckList. On this form they may do as little as just indicate that they have an image of that work that they intend to submit, or they may fill out as much of the form as their time permits.
The Donors then return their completed database files back. The data records in their separate ImageDonorCheckList tables (files) are merged into a single table (or file) and added to the main concordance data.
When all donors have completed describing their submissions there will be two groups of works that can be listed.
Group One constitutes those works to which links to ImageDonorCheckList exist, and Group Two constitutes those works without links. The first group is the HAVE list and the second group is the WANT list.
Because any single image donor may have available more than a single image of the WORK, and because one record is being used to identify one image, the image donor should be able to request that the following record repeat the contents of the previous record, save the repetition of the unique key.
At some future time the values in this file can be parsed out to their respective constituent files as state above.
Structure:
The Work entity and the ImageDonorCheckList entity are linked in a one to many relationship. One Work, as identified in the Work entity may be linked to zero, one or more records in the ImageDonorCheckList entity. The multiple records in ImageDonorCheckList may indicate that one image donor has more than one image to offer for the said work or that more than one image donor has more than one image to offer. During the AIC vetting process, staff and selected art historians will determine from those images offered which are the most likely to be useful to teachers. The images offered may also represent different views of the same work, in which case it may be useful to keep several image per Work.
Vetting Process:
The images identified as being offered by the donors to the AIC go through a vetting process, as cited above. This vetting process expects to be able to rate each image in terms of its utility for teaching. In the grant request sent to the Mellon foundation we proposed the possibility of analyzing the results of the vetting process. These results can be tabulated and linked to the records in the ImageDonorCheckList entity. One way to collect this data is to give the vetting committee an optically readable sheet (like those used for multiple choice examinations) on which they mark one of five categories designating image quality. These can be identified and read and uploaded into a file I've called VettingData. From there statistical data can be developed. Another way is to rate the donated images on-line with members of the vetting committee filling out forms on their laptops. The data in their files can be merged after the process is complete.
For the second level vetting process, the same ImageDonorCheckList records can be used, excluding those that failed the first round. The vetting forms can now indicate that digital images are being judged. This will provide a set of data to compare with the first set. How does the second round committee compare in their assessment of the digital versions of images that the first round committee saw in other media?
Structure:
There is a many-to-one relationship between the VettingData entity and the ImageDonorCheckList entity. Many vetting scores are linked to each image cited in the ImageDonorCheckList. One record in ImageDonorChecklist may have zero, one or many records, attached -- up to the number of individuals in the committee.
Donation Process:
The ImageDonorCheckListFile can form the basis of a catch-all file used to collect images submitted by the community of scholars and others to the Academic Image Cooperative. The Work entity can be used to collect the data submitted with these images. Susan Williams was working on a submission form, and the fields in that form, simpler than those used to catalogue our works, can be made compatible with those in the Allan Kohl's Work entity. The VettingData entity might, then be used to record the opinion of the vetting staff as to the suitability of the images submitted.
This means that the needs of the core editing functions will be served by files that we already have created.
I envision the Work, ImageDonorCheckList and VettingData entities as rudimentary versions of a scratchpad system in which new records and images for the system are contributed, judged and finally cataloged.
FIELDS:
ImageDonerCheckListID
Unique index on this File. The Primary Key. Numbers assigned sequentially. If a record in ImageDonorCheckList is deleted its ID is abandoned permanently. ImageDonorCheckListID links to the VettingData entity with a one-to-many relation: one instance of ImageDonorCheckList to zero, one or many instances of VettingData.
WorkID
Foreign Key. Links to WORK entity. One to Many relation: One record in WORK can link to many records in ImageDonorCheckList.
DonorName
Short form of Donor's Name. This value repeats the last value last entered in each new record, a useful device since donors are working on their own version of this entity. Donor Names are pre-assigned and will be transformed later to numbers to link to a Donor's name/bio file (not implemented).
MyImageReference
This is the code or file-name used by donors to identify their own images. It should be rendered exactly as used by the donor because it may serve as a link to any files received.
ImageFormat
As of now (9/99) we are accepting images in Kodak PhotoCD, Tiff, JPG and GIF files. In 35mm positive and 35mm negative. As 4x5 color transparencies and as photographic prints in B&W or as fine publication images. The image format should be vocabulary controlled to indicate which of the above is being submitted.
ImageSize
ImageSize is used to quantify the ImageFormat data. It is optional on the part of the donor who may not know the values off-hand, but it should be used by staff to keep a record of the resolution or other physical features of the image submitted. Typically the maximum resolution of a digital image is entered or the physical size of a photograph or published image. Note distinction (and potential overlap) between Image Format and Image size: 35mm can be both.
ImageView
ImageView is a text description of the donated image as it relates to the work. For example, for a cathedral, ImageView may be façade, plan, East Porch, etc. For a painting it may be "Detail of Donor's hand," "the Frame," the "rear," "reconstruction by Professor Doe," etc.
An optional authority file should be made available for use here.
Scope Note: In the fully implemented database there is a distinction between a a section of a work that is a work unto itself and a detail or view. Works unto themselves are given their own WorkItem record while details or views are attached to the record of the work they illustrate. But here, in pre-cataloging status, these distinctions are not necessarily honored.
AcceptedFirstVetting
Boolean field filled in by the First Vetting Committee to indicate that the image cited in this record has been accepted to be put forward before the second Vetting committee. The default value is "False" or "N."
AcceptedSecondVetting
Boolean field filled in by the Second Vetting Committee to indicate that the image cited in this record has been accepted to be included in the Prototype set.
Comparison of Vetting Forms and results to be studied and reported upon.
Comment
This is a Memo field for comments, primarily by donors. See Vetting records for Judges Comments.
]
Entity_Connection_One-Name[ ]
Entity_Connection_One_Cardinality[ ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.7]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ VettingData ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The choice of images to present in the AIC is based upon a series of selections in which images are judged in two steps: first in the form (whatever form) presented by contributors and then later as they appear in their digitized manifestation. The Entity (File) named VettingData records (verb) the judges assessment of each image shown. For each image there will be more than one assessment. Each assessment is identified by the name of the assessor and by the ranking given to the image.
Thus far no criteria for ranking has been designated, but it is assumed that ranking will be based on a five-teired system in which #5 represents a quality that the reviewer believes to be the best one could expect to use, and #1 signifies an entirely unusable image.
The method of collecting the data for this file has not yet been determined. One method to do this would be to use preprinted forms that can be read and compiled optically. Another is to provide for direct input through laptops, perhaps.
The purpose of collecting this data is to assess the expectation of quality by media and by judge. There will be two Vetting sessions. The first will look at images in the form in which they were presented. The first Vetting Session will be undertaken by Visual Resources Professionals. The second Vetting Session will consist of images that have been prepared for digital projection (eliminating those images that did not pass Vetting Session number one), and will be conducted by specialist art historians.
The tables (files) VettingData, ImageDonorCheckList and Work may be split off from the main database and used to study issues related to the expected quality of pictures useful for teaching.
It is not clear whether the VettingData records will remain permanently attached to the database. It may be advisable to clear them out every few years or to retire them automatically after some stated interval.
Structure:
There is a one-to-many relationship between the ImageDonorCheckList entity and the VettingData entity. One instance of ImageDonorCheckList may be lined to zero, one or multiple instances of the VettingData entity.
FIELDS:
VettingID
VettingID is the a key field in the VettingData file. Its values are assigned sequentially and are retired when records are removed or deleted.
ImageDonorCheckListID
This is the foreign key that links the many vetting records to a single donor image.
WorkID
WorkID was added by VISIO automatically as a foreign key. It is an artifact and its use will create a false association between vetting score and a work. The correct association is between the vetting score and an image of a work.
JudgeName
JudgeName is the name of the person ranking the image. It should be an item of controlled nomenclature and should link back to a database that contains contact and biographical information on Academic Image Cooperative
administration and workers. [This database has not been implemented in the diagrams.]
Rank
An integer between 1 and 5. Zero is the default and signifies that the judge could not (or did not) rank the image.
Comment
Comment is a field reserved for the comment of the judge.
]
Entity_Connection_One-Name[ ]
Entity_Connection_One_Cardinality[ ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.8]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ WorkItem ]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ WorkItem it the main record for a cataloged work of art, its Key field, WorkItemID, identifies the work. Here it is represented summarily in order to show the relationship between the Concordance entities and the rest of the database.
One-to-many relationship. One WorkItem record may link to zero, one or many records in the PlateToWorkAssociation entity.
The PlateToWorkAssociation identifies those works that correspond to particular plates in particular textbooks. Only those WorkItem records that are linked to the PlateToWorkAssociation table belong to the Concordance. Those works that have no link do not belong to the Concordance.
]
Entity_Connection_One-Name[ ]
Entity_Connection_One_Cardinality[ ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[1.9 ]
DIAGRAM_NAME[ Concordance ]
Entity_Name[ Display Category ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The entities called DisplayCategory, PrimaryDivision, SecondaryDivision and TertiaryDivision represent an attempt to produce a three tier hierarchical structure with with to label each work cataloged in the entity Work. Basically this structure is a "kludge" that attempts to achieve the results seen in TextChapterHead which achieves more versatile results through a recursive relationship. The data coded in the Display Category entities and its satellites should be re-entered into the TectChapterHead structure and these current structures should be deleted.
]
Entity_Connection_One-Name[ ]
Entity_Connection_One_Cardinality[ ] 1)1:1, 2)1:M, 3)M:M
Entity_Connection_One_Direction[ ] Parent / Child
Manditory[ ] or
Optional[ ]