Academic Image Cooperative
Data Model Entity Definitions
SortOrder[4.00]
DIAGRAM_NAME[ Attribution]
Diagram_Description[ -
The Attribution Diagram covers entities that tend to be assigned to works of art by virtue of the opinion of experts, by tradition, or by criteria outside of the work of art itself, for instance by reliance upon documentation or provenance. Unlike books, most works of art do not carry with them the identity of their authors or origins. Consequently, some of the identifications we tend to take for granted come to us as a result of debate and adjudication of the court of opinion juried by experts and other interested individuals. This notion for many may be difficult at first to accept since so many modern works are known, without doubt, to be the work of this or that master whose biography is fairly well documented. But even in the realm of modern painting there is still great uncertainty concerning certain areas, including the early works of well known personages or even disputes regarding authorship that artists, themselves could not solve. For instance, the early cubist paintings of Braque or Picasso in places have not been firmly attributed.
Moreover, the history of art is the history of changing attribution and identifications. Uncertainties (presented as certainties) can cloud the national or cultural origins of works; our identification of objects with known authors, political or stylistic boundaries is always potentially suspect -- abstract constructs that they are. As one of the humanities, the history of art or the history of material culture can be viewed as a key to the evolution of our own thought and values. Revised attributions and the progress (if "progress" is the word) toward modern views are important. Any worthwhile collection of art historical information, therefore must track its own history.
Indeed, any database of information about such works can only appear authoritative and can only be useful as a source of information if the infirm and firm foundations of knowledge about such works are documented.
The Attribution Diagram takes this approach wherever feasible and builds its database architecture on the presumption that information and opinions are dynamic, around the expectation that such information and opinions will evolve and that documenting this evolution is proper to the understanding of art and art history.
The Attribution Diagram inter-relates four kinds of attributed data:
1.The assignment of the Nationality and Culture (VRA Core W.15.) to a work of art.
2.The identification of the work as belonging to a defined Style, Period, Group or Movement (VRA Core W.14).
3.The association of the work with a maker or creator, in all of its manifestations, be it an individual, a close association to an individual, or a corporate body (W.6 -- Creator and W.7. Role)
4.The date or dates when the work was fashioned or made. (VRA Core W.8).
In this diagram, these have been divided into three areas that feed information into the central work-item record (WorkItem) from Authority files where accepted terms needed for cataloging are maintained.
1.The NationalityCulture entity.
2.The StylePeriodGroupMovement entity. And
3.The Attribution entity which handles the connection between works of art and individuals and corporations. The Attribution entity also serves date information into the WorkItem nexus.
Each of these entities are themselves multi-valued, meaning that it is possible to attach more than one Style/Period/Group/Movement record to a work of art, and more than one Nationality/Culture record and more than one attribution to an individual or corporation. Each time an "attribution" association is created the editor has opportunity to record a bibliographic type of citation to the information and to tie that citation to an entry in a bibliographic file. The bibliographic file (represented in summary fashion on this page) can be used to record a variety of information sources, from books and serials, to video-tapes and conversations, web-pages and user contributions.
The three attribution entities: 1) Nationality/Culture, 2) StylePeriodGroupMovement (SPGM) and 3) maker or creator attribution are separated into individually assignable segments. This is done because each of these entities tend to be assigned with different levels of assurance. Nationality and Cultural attributions may be easier to determine than those relating a work to a stylistic group, or association to stylistic group may change from time to time -- especially as regards older less well-known works. Attributions to individuals may be more mercurial and tend to float with opinions regarding the date of manufacture. Further, most works cataloged in the AIC will be assignable without reference to a bibliographical source. Attachments to bibliography will be warranted usually when there is a renouncement of standard and conventional attributions.
The "Attribution" entity also controls the variety of roles individuals and/or corporations play in the making or patronage of a work. The Attribution record structure can be used to record the varying contributions of different individuals, from draftsmen to directors to patrons to founders or conservators.
Each Creator name value is taken from the PersonBio file where information regarding the nationality and life dates or activity dates can be collected. Historical individuals, including artists are often known by a variety of names with distinct orthographic variants among them. The PersonBio file suggests that one form be made authoritative for this collection but recognizes that people may search for other name forms even though they are considered not preferred. Attached to the PersonBio entity is the PersonSearchName entity where both preferred and non-preferred names may be registered for searches.
Attached to the "Attribution" entity is a separate dating module, constructed so that it is possible to assign more than a single span of time to a single attribution.
One area not firmly covered by the VRA core is the relationship between works of art and attributions of proximity to known individuals such as "follower of Leonardo," or "school of Rubens." These works are, in fact, anonymous but their style is so close to that of known masters that art historians have invented a language of associating terms with which to connect them to individuals. Many of these works were at one time attributed to the master; in the future some of these works may be reattributed. No one knows. Simple databases will create an entry into the Artist/Creator file called "School of Rubens" or "Workshop of Rubens." Such a practice manufactures and perpetuates a fiction: it creates a biographical entry for a category that may stand for more than a single person. A much more practical way to construct a relationship between the artist/creator file and such anonymous works is to recognize the proximity in style to the known master and create a link between, say, Rubens and the work from the "School of Rubens," but also employ what I call an "Anonymous Relator," a value placed in the "Attribution" entity that indicates that the work is in the ambience of Rubens and, further, is attributed (in this record) to the "School of Rubens." The technique serves valid art historical purposes. By asking for all images linked to Rubens one can call up all the works attributed to him and those attributed to his circle. (Of course, you can also be more exclusive.)
You'll note that for every Attribution record there can be one or more citation records. The Citation record has a field for the name of the attributor since that name may not appear in the bibliography entry. All attributions, be they attributions of Nationality/Culture, Style or person are documented through the same "AttribCitation" record. By querying this record by the name of the Attributor, the scholar can grasp an image of the work of a single individual. Populating these data records are not expected to be achieved during the development of the AIC prototype system.
One key element of the AIC data structure is its intention to record the data offered by AIC users in the historical and scholarly communities. the three-entity connection that includes "Attribution," "AttribCitation," and "Bibliography" provides a mechanism for recording this kind of data so that it may be accessed by the community. The Bibliography record can keep track of information contributed by the user community so that, if requested these opinions can be filtered out.
Some Authority files, for instance, "NationalityCultureAuthority" and"StylePGMAuthority" will have a tendency to become complex and large files. These entities are built to be recursive -- to be able to run a query on themselves so that the terms can be cataloged in a hierarchical structure. Going from Narrower to Broader terminologies (or the other way around).
Two files, The Corporation file and the PersonBio file use a slightly different recursive device (needs to be proven to work) in which a file serves as an intermediary between two or more records in the main file. The purpose of this intermediary file is to allow the user to specify what kind of relationship is being established between records. For instance the "CorporateRelation" file (pun intended) can be used to point to successor and predecessor corporate bodies. The "PersonRelation" file linked to the "PersonBio" file can be used to plot out family relationship as between the Breughels or master/student relationships. If one artist used different names during different parts of his life (as is done sometimes among Chinese artists, I understand), this device can be used to "kludge" together different preferred names for the same individual and to identify the period or interval during which the temporary name was used.
Finally, Corporations are composed of individuals with biographies. And, of course, individuals belong to corporations, sometimes more than one. These relationships become important in historical studies, for instance, when a corporate body commissions works which are executed by members of that corporation, and in similar situations. It is often useful to be able to record the intertwining relationships between individuals and the organizations to which they belong or for which they work. Guild patronage, fraternal and monastic styles and commissions as executed by individuals can be documented with this tool.
]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[4.01]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ WorkItem ]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
WorkItem is the main record for a cataloged work of art, its Key field, WorkItemID, identifies the work uniquely. Here in the Attribution diagram, it is represented summarily in order to show the relationship between the Attribution entities and the attribution elements of the database built around it.
Structure:
One-to-many relationship: One WorkItem record may link to zero, one or many records in the Nationality/Culture, Style/Period/Group/Movement (SMTM)and the Attribution entities.
This one-to-many arrangement allows the editor to list multiple occurrences of Nationalities, Styles (etc.), and attributions to individuals and/or corporate bodies. Typically such relationships when they are multi-valued are difficult to display in an economical and concise manner as required by the occasional researcher or image-seeker, but they are important for research purposes. In addition, certain constructs that combine more than a single property are difficult to present. A painting may be identified as having been attributed to a number of individuals or may be listed as having been worked on by several individuals in differing capacities, but all the user cares about is "Flemish, Baroque, Rubens." For these situations the WorkItem entity provides "Display Fields" in which the common terms for Nationality, Style designation and authorship can be entered. As mentioned below, anybody who receives this summary display should be notified that more depth is available and should be offered an easy mechanism with which to access these depths.
In the In the Attribute, WorkItem is linked to three dependent entities:
1)Nationality/Culture. One-to-many relationship. One WorkItem record to zero, one or many Nationality/Culture records.
2)StylePeriodGroupMovement. One-to-many relationship. One WorkItem record to zero, one or many StylePeriodGroupMovement records.
3)Attribution. One-to-many relationship. One WorkItem record to zero, one or many Attribution records.
RULES:
A) There is a one-to-many relationship between the WorkItem entity and the NationalityCulture entity. One record in WorkItem may link to many records in NationalityCulture. Through a many-to-many relation, one record in WorkItem may link to Many records in NationalityCulturalAuthority. Note that the NationalityCultureAuthority entity is not an exhaustive listing of all possible nationalities and cultures. It is not definitive, but draws upon such definitive resources as are necessary in order adequately to document the image collection. The values in NationalityCultureAuthority are linked to theNationalityCulture entity. Even so, there may be more NationalityCultureAuthority records than are needed.
The database must prevent duplicate many-to-many links between WorkItem and NationalityCultureAuthority. If a record in NationalityCultureAuthority is to be deleted and that record is linked to one or more records (through NationalityCulture) to WorkItem, the editor must be informed that a linked records is being edited or deleted. Typically the warning should be to delete or reassign the link file (NationalityCulture) so that the record in NationalityCultureAuthority can be changed or deleted.
B) There is a one-to-many relationship between the WorkItem entity and the StylePeriodGroupMovement entity. One record in WorkItem may link to many records in StylePeriodGroupMovement. Through a many-to-many relation, one record in WorkItem may link to Many records in StylePGMAuthority. Note that the StylePGMAuthority entity is not an exhaustive listing of all possible Styles and Movements. It is not definitive but draws upon such definitive resources as necessary in order adequately to document the image collection. Even so, there may be more StylePGMAutority records than are needed.
The database must prevent duplicate many-to-many links between WorkItem and StylePGMAuthority. If a record in StylePGMAuthority is to be deleted and that record is linked to one or more records (through StylePeriodGroupMovement) to WorkItem, the editor must be informed that a linked record is being edited or deleted. Typically the warning should be to delete or reassign the link file (StylePeriodGroupMovement) so that the record in StylePGMAuthority can be changed or deleted.
C) There is a one-to-many relationship between the WorkItem entity and the Attribution entity. One record in WorkItem may link to many records in Attribution. Through many-to-many relations, one record in WorkItem may link to Many records in several Attribution authorities: namely, CreatorRoleAuthority, AnonymousRelationsAuthority, Corporation. Note that the attribution authorities are not exhaustive listings of all possible values. These lists are not definitive but draw upon such definitive resources as is necessary in order adequately to document the image collection.
The database must prevent duplicate many-to-many links between WorkItem and the constellation of Attribution entity authority files.If a record in any of the Attribution files is to be deleted or changed, all links to it must be removed first. The editor must be informed that a linked record is being edited or deleted.
For Display Categories: These fields are used to identify those values that are commonly used to identify the work cataloged. They should be taken from the linking files (when available). The linking files (except for DateAttribution) contain boolean fields that indicate when a value conforms to these criteria. The boolean field in these cases must be programmed so that in the set of values attached to WorkItem only one boolean value is to be allowed to be "True." Further, in any summary display using the display fields, when more than a single record is attached to the item, an indicator should show how these items should be retrieved. I would prefer a button to be placed next to such values which, when pressed would open a window listing each related value and that further action will open additional attached records.
FIELDS:
WorkItemID
WorkItemID is the key field for WorkItem. The value of WorkItem is assigned serially and corresponds to the values defining the WorkId field in the temporary Concordance-entity WORK table. Beginning at some value superior to the last assigned value in the Work table.
WorkNatCulDisplay
This field and the other "Display" fields in this entity are distillations of the most important information recorded in the multi-valued files linked to WorkItem. Their purpose is to insure that simple direct information is available to those who need to know just the most salient information about the object they have requested. For these people, because the database need not process a series of perhaps lengthy relationships, the Display fields may be useful in speeding up reports and queries.
The value in WorkNatCulDisplay should be identical to one value in the NationalityCultureAuthority entity that is linked to WorkItem through NationalityCulture. The entity NationalityCulture contains a Boolean field called NationalityCultureforDisplay. When this value is "True" the value to which the associated record links should be written (as a lookup) into the field WorkNatCulDisplay. Every time a value in NationalityCulture is saved to disk a lookup should determine if the value in WorkTanCulDisplay needs to be updated, and if so should update the WorkNatCulDisplay field.
WorkSPGMDisplay
See description above.
The value in WorkSPGMDisplay should be identical to one value in the StylePeriodGroupMovementAuthority that is linked to WorkItem through the StylePeriodGroupMovement entity. The entity StylePeriodGroupMovement contains a Boolean field called StylePGMforDisplay. When this value is "True" the value to which the associated record links should be written (as a lookup) into the field WorkPGMDisplay. Every time a value in StylePeriodGroupMovement is saved to disk a lookup should determine if the value in WorkSPGMDisplay needs to be updated, and if so should update the WorkSPGMDisplay field.
WorkMakerDisplay
The editor must manually insert the name of a Maker into the WorkMakerDisplay field. The name should be in a convention form as might be found in an exhibit catalogue. If several Attribution entity records are attached to the WorkItem record the editor must determine which one or several should be selected. There is no lookup or automatic validation that is used in conjunction with this field.
WorkDateDisplay
The editor must manually insert a date for the object as recorded in the one or several records attached to the Attribution entity record used to provide information for the WorkMakerDisplay field. There is no lookup or automatic validation that is used in conjunction with this field.
NOTE:
This is an incomplete listing of fields for this entity. See other occurrences of WorkItem in these papers.
]
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[4.05]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ NationalityCulture ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ] or
Associative_Entity[ x ] or
Subset_Entity[ ]
Entity_Description[ -
NationalityCulture is a dependent linking entity that connects its corresponding authority entity (NationalityCultureAuthority) either to the WorkItem entity in order to characterize a work or to the PersonBio entity in order to characterize a person. NationalityCulture corresponds to the VRA Core standard number W.15. With respect to works of art it answers the question "With what nationality or cultural entity is the work associated?" Nationality/Culture is also used to characterize individuals cataloged in the PersonBio file. With respect to persons Nationality/Culture answers the question: "With what nationality or cultural entity is this person associated?"
The Corporation entity contains a field called CorpAssocNationality. No link is built from NationalityCulturalAuthority, to the Corporation entity, but one might be built to feed the above-noted field.
Structure:
NationalityCulture is linked to four entities: 1) NationalityCultureAuthority, 2) WorkItem, 3) PersonBio, and 4)AttribCitation.
1.With the NationalityCultureAuthority entity NationalityCulture shares a one-to-many relationship. One record in the authority file NationalityCultureAuthority may have zero, one or more records in NationalityCulture. One record in NationalityCulture may be linked to one record in NationalityCultureAuthority.
2.NationalityCulture is related to WorkItem via a one-to-many relationship. One record in WorkItem can link to zero, one or many records in NationalityCulture.
3.NationalityCulture is related to the PersonBio entity via a one-to-many relationship. One record in PersonBio can link to multiple records in NationalityCulture.
4.NationalityCulture is related to the AttribCitation entity. One record in NationalityCulture can link to multiple records in AttribCitation. The purpose of the link to AttribCitation is to document assignments of objects to terms of NationalityCulture. These features typically will only be used when there is some kind of dispute or when insufficient work has been done on an object to determine the cultural attribution of that object (this happens).
RULES:
1.If a NationalityCulture record is created, before it is stored it must have a link to the NationalityCultureAuthority.
2.It must also have a link either to the WorkItem entity or to the PersonBio entity, but not to both.
3.Any record in the NationalityCulture entity may have a link to the AttribCitation entity. This link is optional.
4.If a record in the NationalityCultureAuthority entity is linked to one in the NationalityCulture entity, the NationalityCultureAuthority record may not be deleted or edited until it is unlinked from the NationalityCulture record. This means that a new link to NationalityCultureAuthority (if one is to exist at all) must be forged for the NationalityCulture record before the link to the old NationalityCultureAuthority record is dissolved.
5.The same procedure holds true for links between the PersonBio entity and NationalityCultureAuthority.
6.In the NationalityCulture entity the field named NationalityCultureForDisplay is a Boolean field that is allowed to be switched on (made True) only once among records linking values in the NationalityCultureAuthority entity to the WorkItem entity. The rest of the records are marked "False" which should be the field's default value. The field may also be turned on in one record that links a value in the NationalityCultureAuthority entity to the PersonBio entity.
FIELDS:
NationalityCultureID
This is the primary key field for the entity NationalityCulture. Each value is unique. Old values are deleted and are not replaced. The values of NationalityCultureID are assigned sequentially. This field is used to establish a link between the NationalityCulture entity and the Citation file called AttribCitation.
WorkItemID
WorkItemID is a foreign key used to establish links between the NationalityCulture entity and the WorkItem entity. See rules (above) for assigning values to this field.
NationalityCultureAuthorityID
This is a foreign key used to establish links between the NationalityCulture entity and the NationalityCultureAuthority entity. See rules (above) for assigning values to this field.
PersonBioID
This is a foreign key used to establish links between the NationalityCulture entity and the PersonBio entity. See rules (above) for assigning values to this field.
NationalityCultureForDisplay
This is a boolean field that indicates that the associated record in NationalityCultureAuthority may be copied into the WorkNatCulDisplay field in the WorkItem entity. See rules (above) for assigning values to this field.
]
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[ 4.10 ]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ StylePeriodGroupMovement ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ] or
Associative_Entity[ x ] or
Subset_Entity[ ]
Entity_Description[ -
StylePeriodGroupMovement is a dependent linking entity that connects its corresponding authority entity (StylePGMAuthority) to the WorkItem entity in order to characterize a work by assigning it a stylistic identity. StylePeriodGroupMovement corresponds to the VRA Core standard number W.14. With respect to works of art it answers the question "What stylistic characteristics does the work have or with what group, period, or movement is the work commonly affiliated?"
Structure:
StylePeriodGroupMovement is linked to three entities: 1) StylePGMAuthority, 2) WorkItem and 3) AttribCitation.
1.With the StylePGMAuthority entity StylePeriodGroupMovement shares a one-to-many relationship. One record in the authority file StylePGMAuthority may have zero, one or more records in StylePeriodGroupMovement. One record in StylePeriodGroupMovement may be linked to one record in StylePGMAuthority.
2.The StylePeriodGroupMovement authority is related to WorkItem via a one-to-many relationship. One record in WorkItem can link to zero, one or many records in StylePeriodGroupMovement. One record in StylePeriodGroupMovement can link to one record in WorkItem.
3.StylePeriodGroupMovement is related to the AttribCitation entity. One record in StylePeriodGroupMovement can link to multiple records in AttribCitation. The purpose of the link to AttribCitation is to document assignments of objects to terms of StylePeriodGroupMovement. These features will generally only be used when there is some kind of dispute or when insufficient work has been done on an object to determine the cultural attribution of that object (this happens).
RULES:
1.If a StylePeriodGroupMovement record is created, before it is stored it must have a link to the StylePGMAuthority.
2.It must also have a link either to the WorkItem entity.
3.Any record in the StylePeriodGroupMovement entity may have a link to the AttribCitation entity. This link is optional.
4.If a record in the StylePGMAuthority entity is linked to one in the StylePeriodGroupMovement entity, the StylePGMAuthority record may not be deleted or edited until it is unlinked from the StylePeriodGroupMovement record. This means that a new link to StylePGMAuthority (if one is to exist at all) must be forged for the StylePeriodGroupMovement record before the link to the old StylePGMAuthority record is dissolved.
5.In the StylePeriodGroupMovment entity the field named StylePGMForDisplay is a Boolean field that is allowed to be switched on (made True) only once among records linking values in the StylePGMAuthority entity to the WorkItem entity. The rest of the records are marked "False" which should be the field's default value.
FIELDS:
StylePeriodGroupMovementID
This is the primary key field for the entity StylePeriodGroupMovement. Each value is unique. Old values are deleted and are not replaced. The values of StylePeriodGroupMovementID are assigned sequentially. This field is used to establish a link between the StylePeriodGroupMovement entity and the Citation file called AttribCitation.
WorkItemID
WorkItemID is a foreign key used to establish links between the StylePeriodGroupMovement entity and the WorkItem entity. See rules (above) for assigning values to this field.
StylePGMAuthorityID
This is a foreign key used to establish links between the StylePerioudGroupMovement entity and the StylePGMAuthority entity. See rules (above) for assigning values to this field.
StylePGMForDisplay
This is a boolean field that indicates that the associated record in StylePGMAuthority may be copied into the WorkSPGMDisplay field in the WorkItem entity. See rules (above) for assigning values to this field.
]
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[4.15]
DIAGRAM_NAME[ Attribution]
Entity_Name[ NationalityCultureAuthority]
Entity Type
Independent_Entity[x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The NationalityCultureAuthority entity is an authority file that provides the terminology needed to characterize both works of art and biographical information, which it does through a link to the NationalityCulture entity. The NationalityCultureAuthority entity corresponds with the need to serve the definition of the VRA Core (v. 2.0) category W.15: Nationality/Culture. As such its data may be used to answer the question: "With what nationality or cultural entity is the work [or person] associated?" For guidelines, consult the VRA Core Categories at http://www.oberlin.edu/~art/vra/wc1.html.
The set of fields used in this authority file is derived from the Nationality/Culture Authority template designed by Susan Williams (Yale) for use with FileMaker Pro, but is supplemented with a few additional fields and a recursive structure that aids in the organization of terminology by allowing broader and narrower terms to be defined and by allowing non-preferred terms to be listed and linked to their preferred equivalent.
Structure:
1.NationalityCultureAuthority is linked to NationalityCulture in a one-to-many relationship. One record in NationalityCultureAuthority may be linked to zero, one or many instances of NationalityCulture through the primary key, NationalityCultureAuthorityID, in NationalityCultureAuthority and the foreign key in NationalityCulture. One instance of NationalityCulture must be linked to one instance of NationalityCultureAuthority.
2.Through its primary key, NationalityCultureAuthorityId, the entity NationalityCultureAuthority may be linked to zero, one or many instances of itself by linking to foreign key NationalityCultureAuthorityID/1. The foreign key NationalityCultureAuthorityID/1 may be linked to zero or one instance of NationalityCultureAuthority through the primary key NationalityCultureAuthorityID.
RULES:
The entity NationalityCultureAuthority may contain records that are not linked to NationalityCulture. Catalogers may wish to enter terminology that is not currently being used, which may have a high likelihood of being used or that is likely to be the subject of a search in the NationalityCultureAuthority entity or where it may be important to provide information on the term even though no works are cataloged as using it.
In addition, non-preferred terms will not be allowed to be linked to any instance of NationalityCulture. Instead, using the recursive structure non-preferred terms are pointed to records for preferred terms. The Boolean field named NCPreferredTerm defaults to "True." When it is set to "False" then no link to NationalityCulture is allowed, but a link to a preferred term (through NationalityCultureAuthorityID/1) is required. Preferred terms must precede in existence instances of non-preferred terms.
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.
FIELDS:
NationalityCultureAuthorityID
NationalityCultureAuthorityID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as two foreign keys: 1) as NationalityCultureAuthorityID in NationalityCulture, and 2) as the recursive devise: NationalityCultureAuthorityID/1 in itself.
NationalityCultureAuthorityID/1
This is the recursive foreign key that corresponds to NationalityCultureAuthorityID. Values in this field are indexed but not for uniqueness. Values may represent the primary key of broader terms or the primary key of preferred terms when the current record holds a non non-preferred term. See discussions below.
NCDateEdited
This field records the last date a change was made to a record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in an editing mode. It takes the system date and is filled in automatically. No user input.
NCWhoEdited
This field records the name of the last person to change a record in the NationalityCultureAuthority entity or the name of the person who creates a new record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in editing mode. The value in this field should be taken via lookup into a database of individuals with authority to change records. That database should also keep track of other individuals who work on the AIC program even though they do not change the AIC data. This database and its associated lookups into other "WhoEdited" or "WhoAssigned" fields is not shown in this ER diagram.
NCTerm
This field records the terminology used for nationality or cultural identification. It is required and is indexed for uniqueness. Sources may derive from the AAT or other guides. The guidelines published in the VRA Core Categories indicate that this field may record geopolitical divisions where an item was produced or found (the assumption being that an item is found where it was produced or if not the location found points to a set of similar objects found in or near the location. Check the difference between the use of NationalityCulture and W.13 (Original Site).
NCAssocNationality
NCTerm can hold the names of geopolitical areas that no longer exist or which are currently subsumed within larger domains or whose original boundaries now belong to more than a single entity. Art historical classifications frequently, though inexactly, catalogue the name of the current geopolitical entity that corresponds to the location cited in the NCTerm.
This field holds the name of the nationality currently associated with the cultural division or geopolitical entity used for NCTerm.
NCCountryModEquiv
The preferred form for NCTerm and NCAssocNationality is adjectival. (Examples given: English, Japanese, Sienese, Phrygian, Aztec, Berber.) The NCCountryModEquiv provides the nominative version of the modern country that is the approximate (or exact) equivalent of the NCTerm.
Date Fields
AIC uses a set of six or seven field in which to render dates. All dates are given in "earliest" and "latest" forms and are conditioned each with two fields: a descriptor to provide annotations such as "before," "after," "circa," These values should be programmed into the entry form or should be made user accessible in an associated table (not shown). Another annotation form, the "calendar" indicates the kind of dating system being used.
DateRangeEarlyDescriptor
Somtimes called a "date prefix" field the DateRangeEarlyDescriptor provides a terminology that indicates how the date entered in the DateRangeEarly field is to be interpreted. It includes terms like circa, before, after, documented, etc. A question mark may be used to indicate unsureness.
DateRangeEarly
An integer that indicates the earliest date in a range that properly characterizes the period during which the NCTerm applies. Because this field (with DateRangeLate) may be used to query a variety of terms in the NationalityCultureAuthority entity, it is better to err on the side of more inclusiveness (earlier) than on the side of less inclusiveness (later).
DateRangeEarlyCalendar
The DateRangeEarlyCalendar is usually limited to an indication as to whether the integer placed in the DateRangeEarly field is BCE or CE (BC or AD) Dates marked as BCE are usually treated as negative values from the standpoint of processing queries.
Dating functions built into information managers may not properly address the needs of historical databases and are generally, therefore, not used.
It is possible to use the DateRangeEarlyCalendar (and the DateRangeLateCalendar) field to register dates in the Julian calendar and others not consistent with our own but it is suggested to convert these into current notation. If it is required to record date ranges using alternate calendars or perhaps reign information use the NCTermNote field.
DateRangeLateDescriptor
DateRangeLate
DateRangeLateCalendar
Equivalent to the "Early" versions of the date fields except that these fields describe and modify the end of the range of applicibility.
NCBroaderTerm
The term represented by the primary key (NationalityCultureAuthorityID) always identifies a unique term. If a broader term exists then the value of the Primary Key (NationalityCultureAuthorityID) of that term is entered into the foreign key field NationalityCultureAuthorityID/1. A lookup into the record where NationalityCultureAuthorityID is equal to NationalityCultureAuthorityID/1 can retrieve the value of the term broader than the current term. Thesaurus rules requires that there be only one broader term per entry. The form should be programmed so that by hitting the broader term field the user is taken to the appropriate record.
To find narrower terms (see instructions for TextChapterHead entity on the Concordance diagram), in this case the user would be looking for links that flow from the key field NationalityCultureAuthorityID. There are two possible directions to travel from this field: 1) into the NationalityCulture entity, and 2) recursively into the NationalityCultureAuthority entity by way of the NationalityCultureAuthorityID/1 field. By limiting the query to option #2, above. A list of narrower terms can be obtained.
NCPreferredTerm
This Boolean field indicates that the cataloged term is a preferred. usage. The default value of the field is "True" (or "Y"). When the value is "False" the term in the NCTerm field is not-preferred and the value of the NationalityCultureAuthorityID/1 foreign key links to the NationalityCultureAuthorityID of the preferred value term.
For non-preferred term the NCBroaderTerm lookup is not executed. (An alternate solution would be to create a field that reports either "Broader Term" or "Preferred Term" that physically precedes the field for NCBroaderTerm and allow the lookup to take place. That way the value in the (currently named) NCBroaderTerm field will either be a broader term or the corresponding preferred term.
NCTermNote
This is a memo field in which to record scope notes and definitions germane to the NCTerm field or other elements of this entity. If reigns or alternate calendars have been used to determine the date values, notice should be made here.
NCAuthority
The name of the authority from which the NCTerm has been taken.
]
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[ 4.20 ]
DIAGRAM_NAME[ Attribution]
Entity_Name[ StylePGMAuthority]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The StylePGMAuthority entity is an authority file that provides the terminology needed to characterize works with an indicator of a work's Style, Period, Group or Movement, which it does through a link to the StylePeriodGroupMovement entity. The StylePGMAuthority entity corresponds with the need to serve the definition of the VRA Core (v. 2.0) category W.14: Style/Period/Group/Movement. As such its data may be used to answer the question: "What stylistic characteristic does the work have, or with what group, period or movement is the work commonly affiliated?" For guidelines, consult the VRA Core Categories at http://www.oberlin.edu/~art/vra/wc1.html.
The set of fields used in this authority file is derived from the Style/Period/Group/Movement Authority template designed by Susan Williams (Yale) for use with FileMaker Pro, but is supplemented with a few additional fields and a recursive structure that aids in the organization of terminology by allowing non-preferred terms to be listed and linked to their preferred equivalent.
Unlike the NationalityCultureAuthority entity this entity StylePGMAuthority does not contain date fields. This omission may be in error since each of the elements tracked here are circumscribed by date parameters.
Structure:
1.StylePGMAuthority is linked to StylePeriodGroupMovement in a one-to-many relationship. One record in StylePGMAuthority may be linked to zero, one or many instances of StylePeriodGroupMovement through the primary key, StylePGMAuthorityID, in StylePGMAuthority and the foreign key in StylePeriodGroupMovement. One instance of StylePeriodGroupMovement must be linked to one instance of StylePGMAuthority.
2.Through its primary key, StylePGMAuthorityId, the entity StylePGMAuthority may be linked to zero, one or many instances of itself by linking to foreign key StylePGMAuthorityID/1. The foreign key StylePGMAuthorityID/1 may be linked to zero or one instance of StylePGMAuthority through the primary key StylePGMAuthorityID.
RULES:
The entity StylePGMAuthority may contain records that are not linked to StylePeriodGroupMovement. Catalogers may wish to enter terminology that is not currently being used, which may have a high likelihood of being used or that is likely to be the subject of a search in the StylePGMAuthority entity or where it may be important to provide information on the term even though no works are cataloged as using it.
In addition, non-preferred terms will not be allowed to be linked to any instance of StylePeriofGroupMovement. Instead, using the recursive structure non-preferred terms are pointed to records for preferred terms. The Boolean field named SPGMAuthorized defaults to "True." When it is set to "False" then no link to StylePeriodGroupMovement is allowed, but a link to a preferred term (through StylePGMAuthorityID/1) is required. Preferred terms must precede in existence instances of non-preferred terms.
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.
FIELDS:
StylePGMAuthorityID
StylePGMAuthorityID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as two foreign keys: 1) as StylePGMAuthorityID in StylePeriodGroupMovement, and 2) as the recursive devise: StylePGMAuthorityID/1 in itself.
StylePGMAuthorityID/1
This is the recursive foreign key that corresponds to StylePGMAuthorityID. Values in this field are indexed but not for uniqueness. Values represent the primary key of preferred terms when the current record holds a non non-preferred term. See discussions below and elsewhere.
SPGMDateEdited
This field records the last date a change was made to a record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in an editing mode. It takes the system date and is filled in automatically. No user input.
SPGMWhoEdited
This field records the name of the last person to change a record in the StylePGMAuthority entity or the name of the person who creates a new record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in editing mode. The value in this field should be taken via lookup into a database of individuals with authority to change records. That database should also keep track of other individuals who work on the AIC program even though they do not change the AIC data. This database and its associated lookups into other "WhoEdited" or "WhoAssigned" fields is not shown in this ER diagram.
SPGMTerm
This field records the terminology used for to identify stylistic or group associations. This field is required and is indexed for uniqueness. Sources may derive from the AAT or other guides. The guidelines published in the VRA Core Categories indicate that this field may record some terms that are geographically derived (Etruscan, Limosine) or historical, recording works produced under the reign of a certain monarch. There is a potential for this group of terms to become confused with the National/Culture group described elsewhere. The main difference is that this group of terms describe characteristics of the work or of the ideas that produced the work, while the other group shows the influence of nationality or culture. Check the difference between the use of NationalityCulture and W.13 (Original Site).
The VRA Core categories mentions that the terminology used for Styles, Periods, Groups and Movements might be best handled using hierarchically composed records -- as we defined for the NationalityCultureAuthority entity. Susan Williams, after whose FileMakerPro template this entity is designed has divided the set of terms into groups defined as "Styles," "Periods," "Groups" and "Movements." Unless this structure eventually proves unusable we will use the structure and terminology she has defined.
SPGMTermType
A field for the values: Style, Period, Group or Movement to characterize the term placed in the SPGMTerm field.
SPGMAuthority
The name of the authority or source from which the SPGMTerm has been taken or derived.
SPGMTermAuthorized
This Boolean field indicates that the cataloged term is a preferred usage. The default value of the field is "True" (or "Y"). When the value is "False" the term in the SPGMTerm field is not-preferred and the value of the NationalityCultureAuthorityID/1 foreign key links to the NationalityCultureAuthorityID of the preferred value term.
SPGMNotes
This is a memo field in which to record scope notes and definitions germane to the SPGMTerm field or other elements of this 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[4.25]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ Attribution]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ] or
Associative_Entity[ x ] or
Subset_Entity[ ]
Entity_Description[ -
The Attribution entity coordinates the integration of several interrelated authority lists as they combine their values to form records that connect individual and corporate bodies with acts relative to the making and creation of art and with other activities associated with works of art.
In the Attribution entity 1) a work may be attributed to a person or persons. 2) Other activities performed in relation to a work may be documented. 3) Corporate roles may be defined. 4) The work may be dated. 5) Anonymous works may be associated with known masters. 6) Differing opinions regarding the forgoing may be registered, including 7) Contributor information may be recorded. 8) Opinions may be linked to citations and to bibliographic or related records.
To achieve these goals the Attribution entity acts as a way-station where elements deriving from the following authority files may be combined to form a single "attribution record."
1.PersonBio: An entity that records the biographical data of individuals who may have played a role in the production of a work of art.
2.Corporation: An entity that records crucial data regarding the name of a corporation, the location of its activities, and its period of activity.
3.CreatorRoleAuthority: This entity is an authority list of the kinds of activities or roles people play in the creation of works of art. Terms may be derived from the AAT (for instance the <people by activity> facet or the <people by occupation> facet, or the <craftsmen> facet which includes <people in the crafts or trades> or <people in the visual arts and related professions>, etc. Terms such as patron, conservator, are appropriate. With some modification this entity can be made to track provenance, but without modification the role of "owner" with appropriate dates may serve well.
4.AnonymousRelationsAuthority: This entity is used only when a work is so closely allied to the style of a known master that connoisseurs use the name of that master to identify the style. Terms such as "School of Rubens," "follower of Caravaggio," all indicate that the identity of the artist is unknown. These cases, it would seem should use terminology held in the StylePersonGroupMovementAuthority file. My preference is to link these records to the biographical entry of the associated artist but to make certain that a value from the AnonymousRelationsAuthority file is placed in the Attributions record. There is a wide variety of these terms to place before the name of the chosen maker: "School of," "In the style of," "Copyist of," etc.
5.DateAttribution: The entity for recording object dates is attached to the Attribution record for reasons explained below. You will not that is is possible to attach more than a single date record to a single attribution record. This allows for multi-valued dates to be recorded as when work on a project or work takes place in multiple discrete intervals.
6.Each Attribution entity record can be linked to one or several AttribCitation records. This permits several bibliographic items to be represented by one attribution.
Problem:
7.The AttributionStatus entity helps identify the nature of the attribution link. Because Attribution entity records can record relationships of all kinds, it is necessary to distinguish between unconventional attributions, traditional attributions, and nearly any variety of opinion concerning the acting agents (in PersonBio and Corporation) -- even a rejection of attribution.
Structure:
1.The Attribution entity is linked to WorkItem entity records in a one-to-many relation. One WorkItem record may have zero, one or many instances of Attribution records.
2.The Attribution entity is linked to the PersonBio entity in a one-to-many relationship. Each Attribution record is allowed to link to zero or one record stored in the PersonBio file. But one record in the PersonBio file can link to zero, one or many Attribution records. Link from Attribution to PersonBio is not mandatory.
3.The Attribution entity is linked to the Corporation entity in a one-to-many relationship. Each Attribution record is allowed to link to zero or one record stored in the Corporation file. But one record in the Corporation file can link to zero, one or many Attribution records. Link from Attribution to Corporation is not mandatory.
4.The Attribution entity is linked to the DateAttribution entity in a one-to-many relationship. Each Attribution record is allowed to link to zero, one or many DateAttribution records. But one DateAttribution record may be linked to only one Attribution record. A DateAttribution record may not exist unlinked to an Attribution record.
5.The Attribution entity is linked to the AnonymousRelationsAuthority entity in a one-to-many relationship. It is not advisable to drive home after a one-to-many relationship. Take a taxi. Each Attribution record is allowed to link to zero or one record stored in the AnonymousRelationsAuthority file. But one record in the AnonymousRelationsAuthority file can link to zero, one or many Attribution records. Link from Attribution to AnonymousRelationsAuthority is not mandatory.
6.The Attribution entity is linked to the CreatorRoleAuthority entity in a one-to-many relationship. One CreatorRoleAuthority record may link to zero, one or more Attribution records. But one Attribution record can link to only one CreatorRoleAuthority record.
7.AttribCitation: The Attribution entity is linked to the AttribCitation entity in a one-to-many relationship. One instance in the Attribution entity can link to zero, one or many instances in the AttribCitation entity. One instance in the AttribCitation entity can link to one instance in the Attribution entity.
8.AttributionStatus: The Attribution entity is linked to the AttributionStatus entity in a one-to-many relationship. One instance in the AttributionStatus entity can link to zero, one or many instances in the AttributionStatus entity. One instance in the Attribution entity can link to one instance in the Attribution entity.
RULES:
1.Each Attribution record records a single attribution. One individual or one Corporation. The data structure already prohibits more than one Corporation from sharing an Attribution record and prhohibits more than one person (in a PersonBio record) from sharing an Attribution record. In addition there must be a rule that forces an Attribution record from linking to a PersonBio record an a Corporation record. An Attribution record may link to neither a PersonBio record nor to a Corporation record.
2.The existance of a DateAttribution record linked to the Attribution record is optional. (But a DateAttribution record may not exist without being linked to an Attribution record.) A DateAttribution record may exist as the only entity linked to an Attribution record.
3.The CreatorRoleAuthority entity may or may not be linked to the Attribution record. (Records in CreatorRoleAuthority may exist without being linked to the Attribution record.) Use of the CreatorRoleAuthority must be used with discretion. In most cases the role of the attributed artist will be obvious, and therefore should not be linked to a record in the CreatorRoleAuthority entity. It is only when multiple roles are being defined and/or multiple contributors to a work exist that it will become necessary to link values in the CreatorRoleAuthority. Sometimes, if a creator's role is one that is unusual for him, it may be advisable to specify it through CreatorRoleAuthority.
4.The AnonymousRelationsAuthority is linked into the Attributions record only when the current attribution is anonymous but is related in attribution to the name of a known person. When this link appears it should be understood that the work is anonymous. This link should be allowed to form only for Attribution records that point to a record in the PersonBio file, not to named Corporations.
5.An AttribCitation record may not exist as the only record linked to an Attribution record. An AttribCitation record may not exist without being linked to an Attribution record. To delete an Attribution record it will be necessary first to delete the DateAttribution record link and the AttribCitation record.
6.An AttributionStatus record may only exist linked to the Attribution entity record if either a Corporation or a PersonBio is also linked to an Attribution entity record.
7.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.
FIELDS:
AttributionID
AttributionID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as foreign keys: 1) as AttributionID in DateAttribution, 2) as AttributionID in AttribCitation 2) as the recursive devise: AttributionID/1 in itself. AttributionID is indexed for uniqueness.
WorkItemID
WorkItemID is a foreign key in the Attribution entity. It establishes a link to the WorkItem file. One WorkItem record may be linked to zero, one or many Attribution records through WorkItemID. (Attribution entity records cannot exist without being linked to a WorkItem entity record.)
WorkItemID in the Attribution Record is is indexed but its values do not need to be unique.
AttribQualifier
AttribQualifier is a text field defined to help enact the rules needed to manage the attachment of records to the Attribution entiry records. Depending upon how the rules are enforced through programming this field may or may not be used. (See Rules, above.)
AttribDateEdited
This field records the last date a change was made to a record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in an editing mode. It takes the system date and is filled in automatically. No user input.
AttribWhoEdited
This field records the name of the last person to change a record in the Attribution entity or the name of the person who creates a new record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in editing mode. The value in this field should be taken via lookup into a database of individuals with authority to change records. That database should also keep track of other individuals who work on the AIC program even though they do not change the AIC data. This database and its associated lookups into other "WhoEdited" or "WhoAssigned" fields is not shown in this ER diagram.
AttribDateNarrative
Sometimes it may be useful to summarize the range of dates recorded in the linked DateAttribution records (especially when more than one DateAttribution record is linked to an Attribution entity record). This field may be used to provide a narrative version of the recorded dates. It is also useful when the dating recorded in the DateAttribution entity is a translation or corruption or simplification of the actual dates, in which case the AttribDateNarrative field will be useful.
AttributionNote
This field holds text notes regarding the nature of the attribution recorded. It may be used when the attribution itself is not easily transformed into recordable and searchable information.
AttribConjunctive
Sometimes it may be advisible to offer the user a means with which to connect the individual records in a set of attributions. The description of a work of art, its placement in cultural and aesthetic contexts is best drawn by using a narrative language -- not the architectural structure of databases. But we need our databases as finding aids and to overcome the ephemeral memory we have for cultural data. Yet we can tie some information together using a recursive relationship for records in the same entity.
For instance, let's say we have a work normaly attributed to Rubens and Jan Breughel, but there exists a credible alternate attribution that considers the work to be entirely by someone else, let's call him Matthias Drunkfeder. Normally we'd have three records in the Attribution entity from the work as described in WorkItem. But two of those attributions records belong together. For these we'd attach a recursive link, say from the Attribution record that leads to Rubens to the Attribution record that leads to Jan Breughel. When such a link exists the AttribConjunctive field is filled with a term that helps us to understand the nature of the relatiohip. For example we'd read this set as "Rubens" "with" "Jan Breughel" if "with" was used as the AttribConjunctive. There is no need to use a controlled vocabulary in the AttribConjunctive field. The attribution to our Matthias Drunkfeder would, in this case, stand alone.
Cagalogers will have to determine the rules for connecting multiple artists with recursive ties.
PersonBioID
PersonBioID is a foreign key linked to the PersonBio entity. It is used to link and/or display the PersonBio record corresponding to the attribution of a work to an individual artist (one attribution per Attribution record). The PersonBio entity has fields in which to record a sort version of a name and a display version (The preferred name). A choice will have to be made whether to display one or the other during searches.
AnonymousRelationsAuthorityID
This is a foreign key that is linked to AnonymousRelationsAuthorityID in the AnonymousRelationsAuthority. It is used only when the individual linked to the Attribution record is not the attributed author of the work, but when the attribution is so close to his reputed style that art historians feel compelled to invoke the name of the artist as part of the attribution. Typically terms such as "Studio of ...," or "Workshop of ...," are used. The default value of this field should be unlinked.
For the editor's version of the AIC database all such linked entities should be available directly from the editing screen while a WorkItem record is current. The editor should be able to query the contents of such entities and then to tie one value into the appropriate field -- all without having to copy or memorize ID numbers. Below is a list of some of these terms created for another project.
¦---------------------------------------------------------¦
¦ DOES NOT APPLY ¦ ¦ ¦
¦ Studio of ¦ ¦ ¦
¦ Workshop of ¦ ¦ Copy of ¦
¦ Assistants of ¦ ¦ Copy After ¦
¦ Pupil of ¦ ¦ After ¦
¦ Companion of ¦ (cf. other ¦ After a design by¦
¦ Circle of ¦ related records) ¦ " a lost work by¦
¦ School of ¦ ¦ Imitator of ¦
¦ ¦ ¦ Adaptation after ¦
+-------------------+------------------+------------------¦
¦ Near ¦ ¦ Class of ¦
¦ Close to ¦ ¦ Group of ¦
¦ Kinship to ¦ Connected to ¦ In sequence of ¦
¦ Follower of ¦ Associated with ¦ In wing of ¦
¦ Style of ¦ ¦ In tradition of ¦
¦ Manner of ¦ Influenced by ¦ Forgery of ¦
¦ Neighborhood of ¦ Restored by ¦ Unknown Relation ¦
¦ ¦ ¦ KILL SELECTION ¦
----------------------------------------------------------+
CreatorRoleAuthorityID
This is the foreign key leading to the CreatorRoleAuthority entidy. The values in that entity can be used only when tha Attribution record points to an individual or a Corporation. These terms may be used to indicate what role or function an individual or corporation played in the creation of a work. For instance, one can use this device to name the guilds that committsions the sculpture on Or San Michele in Florence. Or one can list as "owner" any number of collectors of significance. In these cases, guilds would be listed as corporate bodies (redundancy?) in the Corporation file and owners would be cited in the PersonBio file. Obviously the PersonBio file may be used for more than just creators and artists.
CorporationID
This is the foreign key leading to the Corporation authority file. Guilds, Military Companies, Monastic Orders and other institutions that have played roles in the creation or design of works of art may be listed in the Corporation file. This field allows a link to the Corporation entity in order to link and/or display the name or other information from the Corporation entity file.
AttributionID/1
AttributionID/1 provides opportunity to establish a recursive relationship between records in the access file. It should be used sparingly in conjunction with the AttribConjunctive field to knit together attribution records related to a single work that point to multiple artists. Generally using this field will only be necessary if multiple attributions might cause ambiguity and confusion. It will be used rarely.
WorkItemID/1
This field exists on the VISIO diagram because it was entered automatically by the program. It is an artifact and (as far as I can tell) serves no useful purpose. Nominally it would allow an attribution record for one work to point to another work. There will be a recursive structure build elsewhere that will link one work to another. But this field in this entity is not useful. It if it is created automatically, it should be deleted.
AttributionStatusID
AttributionStatusID is the foreign key that links to the AttributionStatus entity. AttributionStatusID may or may not be linked to a record in AttributionStatus.
]
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[ 4.30]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ PersonBio ]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The PersonBio entity is charged with keeping track of the biographies of individuals that must be tracked by the program. These individuals include, of course, artists and craftsmen, but the file may also be used for any individual whose name may appear in the database records: Patrons and conservators, owners and dealers, printers and studio hands, scholars and teachers. Theoretically the file created by PersonBio should also list individuals who work on or are given editing privileges, but because I have not built an address file to link to the PersonBio data we'll keep staff separate.
This entity is derived from the example provided by Susan Williams's FileMakerPro template.
One of the most common issues faced with keeping track of historical personages is the orthography of names and the syntax in which they are rendered. Multiple names given to individuals or names by which they have been known throughout the ages and in different areas are also problematic. This entity tackles these problems in several ways.
PersonBio requires that the editor choose a single form of a name to serve as the official name by which that individual is cited in the database. Usually that name will be the same as the "preferred name" cited in an authority file such as ULAN (http://shiva.pub.getty.edu/ulan_browser/). The PersonBio entity offers users two forms in which to record the chosen name: 1) inflected for sorting and 2) uninflected for use in a more natural format. Having only a single version of an individual's name available to use creates difficulties for users who may not know which version the AIC has chosen to use. For that reason the PersonBio entity is served by an attached entity called PersonSearchName. In PersonSearchName the official name and every likely variant can be entered in a single file and searched. Because PersonSearchName is linked in a one-to-many relation to PersonBio it is possible to output all the search names in any report produced on a PersonBio file.
Another device attached to the PersonBio entity is an entity called PersonRelation. Working somewhat like a recursive relationship PersonRelation permits any two PersonBio records to be related to each other and permits the editor to identify the nature of the connection. This structure will prove useful under certain circumstances. The most obvious use of the PersonRelation entity is to identify familial relationships among individuals: father/son, siblings, etc.
Another potential use of the PersonRelation record is to handle the relatively rare situation when an artist uses more than one name, and each name refers to a specific body of works. I understand that this is the case for several non-western artists whose name changes with the course of their life. In such a case multiple PersonBio records can be created, linked and identified through PersonRelation.
Finally the entity CorporateIdentity may be used to establish a relationship between any corporation and any individual in the PersonBio file. The logic is simple: A corporation is composed of individuals. Its use for recording art historical information, however, has yet to be proven. From this writer's perspective, however, such a feature can be used to document (in a structural way) relationships between patronage and individuals that have thus far only been put forward in an informal manner.
Structure:
1.The PersonBio entity is linked to the Attribution entity in a one-to-many relationship. One record in the PersonBio entity may be linked to zero, one or many records of the Attribution entity. It is a catalogers decision, but most likely it will be the field PersonBioPreferredName that will be the displayed form in any lookups or linkages. (Decision.)
2.The PersonBio entity is linked to the NationalityCulture entity in a one-to-many relationship. One record in the PersonBio file may link to zero (unlikely), one (likely) or many (unlikely) records in NationalityCulture. The unusual option to link more than a single nationality or culture record to a record in PersonBio serves those occasions when an individual 1) has a separate culture and a separate nationality (as for example members of an Inuit tribe), 2) has changed their nationality through immigration, or 3) when there is debate regarding the proper culture or nationality. For these purposes, the NationalityCulture entity permits a link through the AttribCitation entity to the Bibliography entity. Note that a value linked through NationalityCulture to NationalityCultureAuthority is marked in NationalityCulture as "for display" with a boolean field. This value is imported via a lookup directly into the PersonBio file.
3.The PersonBio entity is linked to the PersonSearchName entity in a one-to-many relationship. One record in PersonBio must be linked to at least one record in PersonSearchName. That one name will be the one in the PersonBioPreferredName field, (Unless catalogers wish it to be the PersonBioSortName). (Decision.)
4.The PersonBio entity is double-linked to the PersonRelation entity. (By this is meant that there are two fields in PersonRelation that can link to the key field in PersonBio). Each link is one-to-many from PersonBio to PersonRelation. For each one record from PersonBio may link to one or more records in PersonRelation. Each record in Person relation MUST be linked to no more and no less than two separate records in PersonBio.
5.The PersonBio entity is linked to the CorporationIdentity entity in a one-to-many relationship. Each record in PersonBio may link to zero, one or many records in the CorporationIdentity file which establishes a many-to-many relationship with the Corporation entity. One corporation may link to many persons and one person may link to many corporations. The CorporateIdentity entity through the CorpIdentityName field establishes the nature of the relationship. Usually this will be expressed as the role of an individual within the corporation.
6.The PersonBio entity is linked to the AttribCitation entity in a one-to-many relationship. One record in the PersonBio file may link to zero, one or many records in AttribCitation. There is a many-to-many relationship established between the Bibliography file and the PersonBio file. One Bibliography entry may link to multiple records in PersonBio and one record in PersonBio may link to multiple Bibliography records.
RULES:
1.A PersonBio record may exist without being linked to theNationalityCulture, Attribution, AttribCitation, CorporateIdentity, and PersonRelation entities, but it must be linked to at least one record in the PersonSearchName entity.
2.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.
FIELDS:
PersonBioID
PersonBioID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as foreign keys: 1) as PersonBioID in PersonalityCulture, 2) as PersonBioID in Attribution 3) as PersonBioID in AttribCitation, 4) as PersonBioId in CorporateIdentity, 5) As PersonBioID and PersonBioID/1 in PersonRelations, and 6) as PersonBioID in PersonSearchName. In PersonBio PersonBioID is indexed for uniqueness.
[Note: I've been using ...DateAssigned and ...DateEdited interchangeably. This should be corrected.]
PersonBioDateAssigned
This field records the last date a change was made to a record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in an editing mode. It takes the system date and is filled in automatically. No user input.
PersonBioWhoAssigned
This field records the name of the last person to change a record in the PersonBio entity or the name of the person who creates a new record. It should be changed only when there is an editing change and created when a new record is created. It should not be updated when a record is viewed or appears in editing mode. The value in this field should be taken via lookup into a database of individuals with authority to change records. That database should also keep track of other individuals who work on the AIC program even though they do not change the AIC data. This database and its associated lookups into other "WhoEdited" or "WhoAssigned" fields is not shown in this ER diagram.
PersonBioSortName
The PersonBioSortName is the form of the name arranged for an alphabetical listing. Ordinarily this should conform with the style guide suggested for ULAN (http://shiva.pub.getty.edu/cgi-bin/ulan_browser) It is suggested that ULAN be used as a guide since the orthography and syntax of names is highly selective and variable and some structure and authority is needed to insure successful searches. In addition a series of search routines that can be called on all authority files should aid this task, among these being partial string searches and showing multiple hits. Because some persons have the same name, this field cannot be indexed for uniqueness. Uniqueness is established by the PersonBioID field.
Note: consider adopting the technique ULAN uses for searches. All entered names are removed of punctuation and spaces. The values must be stored in that fashion for searches.
ULAN favors using the common variant of a name with the precise form trailing in parenthesis.
PersonBioPreferredName
The name of the Person in conventional order. Nicolas Poussin, as opposed to Poussin, Nicolas. But note that many names are not reversed for sorting: Michelangelo Buonarotti.
PersonNationalityCulture
This is the term taken from the NationalCultureAuthority by way of the record in the NationalityCulture entity that is marked by the NationalityCultureForDisplay boolean field as "True." It is the term that is used for all lists of people in the PersonBio entity.
Note that a search through the NationalityCultureAuthority file for other terms that happen to be linked to PersonBio records will find all linked records. Similarly, in spite of the contents of the PersonNationalityCulture field, all other links from a PersonBio record can be discovered through the PersonBio foreign key in the NationalityCulture entity.
PersonCountryModEquiv
The previous field PersonNationalityCulture identifies the historical national or cultural classification associated with the person cited. This field provides an access point that may be easier to use for some individuals. It represents the name of the current country that corresponds to the Nationality or Cultural area cited above. As newcountries form and old countries change their names there may be reason to construct a one-to-many relationship to this field. Until then choose the name of the country most likely to be used by someone who is staging a query.
PersonCountryWhenBorn
This field is used to record the name of the country or geo-political entity into which the individual was born.
PersonBioAuthority
This field is used to name the key biographical reference used to collect information for this entity. Basically it is a redundancy because the AttribCitation entity provides a link from the PersonBio entity through to the Bibliography entity. This text field may be used as a means of entering data quickly that will eventually be moved into the AttribCitation and Bibliography entities.
PBEarlyDateDescriptor
PBEarlyDate
PBEarlyDateCalendar
PBLateDateDescriptor
PBLateDate
PBLateDateCalendar
These date fields define the life dates of the person identified in PersonBio. The descriptor information may include terms like:
circa, active from, flourished from, active to, flourished do. Not the difference between "active" and "flourished." The former is a date range for the productive work of the maker. Flourished describes without benefit of life and/or death dates, when the person was alive.
]
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[ 4.35 ]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ PersonSearchName ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
PersonBio requires that the editor choose a single form of a name to serve as the official name by which that individual is cited in the database. Usually that name will be the same as the "preferred name" cited in an authority file such as ULAN (http://shiva.pub.getty.edu/ulan_browser/). The PersonBio entity offers users two forms in which to record the chosen name: 1) inflected for sorting and 2) uninflected for use in a more natural format. Having only a single version of an individual's name available to use creates difficulties for users who may not know which version the AIC has chosen to use. For that reason the PersonBio entity is served by an attached entity called PersonSearchName. In PersonSearchName the official name and every likely variant can be entered in a single file and searched. Because PersonSearchName is linked in a one-to-many relation to PersonBio it is possible to output all the search names in any report produced on a PersonBio file.
Structure:
PersonSearchName is related to PersonBio in a one-to-many relationship. One record from PersonBio may link to one or more records in PersonSearchName. There must be at least one record in PersonSearchName linked to a record in PersonBio. For every record in PersonBio there must be at least one record in PersonSearchName.
RULES:
See, above: Structure.
FIELDS:
PersonSearchNameID
PersonSearchNameID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does not manifest as a foreign key. In PersonSearchName PersonSearchNameID is indexed for uniqueness.
PersonBioID
This is the foreign key equivalent to PersonBioID in the PersonBio entity.
PSNTerm
This field is used to render the PersonBioSortName value within PersonBio. It would be useful if this record were created automatically the first time the PersonBio file was stored. Additional terms, using the same format as used by ULAN, should also be stored. PSNTerm is a required field and should be indexed in combination with PersonBioID for uniqueness -- in other words, for any single artist no duplicates are allowed. We must acknowledge the possibility that one name may be used by more than one artist.
PSNTermType
Catalogers may which to categorize the PersonName forms they enterinto this entity. Some names are in common use, others, perhaps, are nicknames, sill others are given names or names only found in documents. Alternate spelling are possible, too. This is not a required field.
PSNDateEdited
PSNWhoEdited
These two fields follow the same conventions established for the "..dateEdited," ("..dateAssigned") and "..whoEdited," ("..whoAssigned,") fields defined elsewhere.
]
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[ 4.40]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ PersonRelation ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The PersonRelation entity works something like a recursive structure. It contains two representations of a field that can be linked to the PersonBio key field PersonBioID: PersonBioID and PersonBioID/1. PersonRelation is (what I call) double-linked to the PersonBio entity.
The purpose of PersonRelation is to be able to connect two records in PersonBio and to indicate in PersonRelation the nature of that connection -- what it means.
This structure will prove useful under certain circumstances. The most obvious use of the PersonRelation entity is to identify familial relationships among individuals: father/son, siblings, etc.
Another potential use of the PersonRelation record is to handle the relatively rare situation when an artist uses more than one name, and each name refers to a specific body of works. I understand that this is the case for several non-western artists whose name changes with the course of their life. In such a case multiple PersonBio records can be created, linked and identified through PersonRelation.
Structure:
1.PersonRelation is linked to the PersonBio entity twice. The PersonBioID foreign key field in PersonRelation is linked to PersonBio in a one-to-many relation. Any single record in the entity PersonBio can have zero, one or many records of PersonRelation linked.
2.The PersonBioID/1 foreign key field in PersonRelation is linked to PersonBio in a one-to-many relation. Any single record in the entity PersonBio can have zero, one or many records of PersonRelation linked.
RULES:
1.A PersonRelation record must be linked to two different PersonBio records. A PersonRelation record cannot exist unlinked.
2.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.
FIELDS:
PersonRelationID
PersonRelationID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does not manifest as a foreign key. In PersonRelation PersonRelationID is indexed for uniqueness.
PersonBioID
PersonBioID/1
These are the two foreign keys that link to the PersonBio entity.
According to the rules, both fields must be used and they must connect to different records in PersonBio.
PersonRelationTerm
This field is used to connect two records and to explain that connection. It is suggested that since such connections suggest a relationship defined from one PersonBio record to another, that they be used consistently: Decide that PersonBioID establishes the link and that PersonBioID/1 finishes the link. For instance PersonBioID is the father of PersonBioID/1.
Catalogers will have to decide upon a set of vocabulary terms. For example, if we say that A is the father of B, should we link B to A to say that B is the son of A? This kind of redundancy has to be controlled.
PersonRelationNote
There is going to be a need to take notes and explain relationships established. This Memo field can be used to manage those notes.
]
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[ 4.45]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ CreatorRoleAuthority]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
CreatorRoleAuthority: This entity is an authority list of the kinds of activities or roles people play in the creation of works of art. Terms may be derived from the AAT (for instance the <people by activity> facet or the <people by occupation> facet, or the <craftsmen> facet which includes <people in the crafts or trades> or <people in the visual arts and related professions>, etc. Terms such as patron, conservator, are appropriate. With some modification this entity can be made to track provenance, but without modification the role of "owner" with appropriate dates may serve well.
An entity that I have not included would classify the nature of the attribution. Not all attributions assign works to individuals. Some opinions remove works from an artist's oeuvre and others cast degrees ofdoubt. So another field accessed through the Attribution entity can be used to classify the nature of the attributive statement: "by," "rejected," "possibly by," "counterfeit," etc.
I have not provided for a field in which to record the terminology source. In my opinion this information is relatively unimportant in this case.
Structure:
CreatorRoleAuthority is linked to the Attribution entity in a one-to-many relationship. One record in CreatorRoleAuthority may be linked to zero, one or many records in Attribution. One record in Attribution may be linked to zero or one records in CreatorRoleAuthority.
RULES:
Records in CreatorRoleAuthority may be linked to an Attribution entity record only when either there is also a link to the PersonBio entity or to the Corporation entity. Records in CreatorRoleAuthority may exist without being linked to anything. If a linked record from CreatorRoleAuthority is being edited, all the links to it must be broken first.
FIELDS:
CreationRoleAuthorityID
CreationRoleAuthorityID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does not manifest as a foreign key. In CreationRoleAuthority CreationRoleAuthorityID is indexed for uniqueness.
CreatorRoleTermText
This required field is used to enter the name of the role to be linked through the Attribution file to the attributed Person or Corporation.
CreatorRoleTermNote
A text file in which an editor may make notes.
]
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[ 4.50 ]
DIAGRAM_NAME[ Attribution]
Entity_Name[ AnonymousRelationsAuthority]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
AnonymousRelationsAuthority: This entity is used only when a work is so closely allied to the style of a known master that connoisseurs use the name of that master to identify the style. Terms such as "School of Rubens," "follower of Caravaggio," all indicate that the identity of the artist is unknown. These cases, it would seem, should use terminology held in the StylePersonGroupMovementAuthority file. My preference is to keep these kinds of group names separate, and to link, instead, these records to the biographical entry of the associated artist, but, at the same time, to make certain that a value from the AnonymousRelationsAuthority file is placed in the Attributions record. There is a wide variety of these terms to place before the name of the chosen maker: "School of," "In the style of," "Copyist of," etc.
Structure:
The AnonymousRelationsAuthority entity is linked to the Attribution entity in a one-to-many relationsip. One record in AnonymousRelationsAuthority may be linked to zero, one or many records in the Attribution file. One record in the Attribution authority may link only to one record in the AnonymousRelationsAuthority file.
RULES:
A record in the AnonymousRelationsAuthority entity may exist without being linked to Attribution.
A record in the AnonymousRelationsAuthority may be linked to Attribution only when a record from PersonBio is linked to Attribution.
If a record in AnonymousRelationsAuthority is to be edited, all links to that entity must first be broken. A good strategy is to create a new record with corrections and then change the links from the old record to the new record, then delete the old record.
Usage:
Follow the guidelines presented in the Categories for the Description of World Art: http://www.getty.edu/gri/standard/cdwa/CREATION.HTM
FIELDS:
AnonymousRelationsAuthorityID
AnonymousRelationsAuthorityID is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as a foreign key in the Attribution entity. In AnonymousRelationsAuthority AnonymousRelationsAuthorityID is indexed for uniqueness.
AnonyRelatAuthorityTerm
This field contains the languange that is used to characterize the relationship between the supposed author of the work and the name of the master with whom it is associated.
It is used only when the individual linked to the Attribution record is not the attributed author of the work, but when the attribution is so close to his reputed style that art historians feel compelled to invoke the name of the artist as part of the attribution. Typically terms such as "Studio of ...," or "Workshop of ...," are used. The default value of this field should be unlinked.
For the editor's version of the AIC database all such linked entities should be available directly from the editing screen while a WorkItem record is current. The editor should be able to query the contents of such entities and then to tie one value into the appropriate field -- all without having to copy or memorize ID numbers. Below is a list of some of these terms created for another project.
¦---------------------------------------------------------¦
¦ ¦ ascribed to ¦ ¦
¦ Studio of ¦ atelier of ¦ copyist of ¦
¦ Workshop of ¦ office of ¦ Copy of ¦
¦ Assistants of ¦ assistant to ¦ Copy After ¦
¦ Pupil of ¦ ¦ After ¦
¦ Companion of ¦ ¦ After a design by¦
¦ Circle of ¦ associate of ¦ " a lost work by¦
¦ School of ¦ ¦ Imitator of ¦
¦ ¦ ¦ Adaptation after ¦
+-------------------+------------------+------------------¦
¦ Near ¦ ¦ Class of ¦
¦ Close to ¦ ¦ Group of ¦
¦ Kinship to ¦ Connected to ¦ In sequence of ¦
¦ Follower of ¦ Associated with ¦ In wing of ¦
¦ Style of ¦ ¦ In tradition of ¦
¦ Manner of ¦ Influenced by ¦ Forgery of ¦
¦ Neighborhood of ¦ Restored by ¦ ¦
¦ ¦ ¦ ¦
----------------------------------------------------------+
AnonyRelatAuthorityTermNote
This field is used to explain the meaning, context or history of the term used. There is no special reason to track the location where the term was found.
]
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[ 4.55]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ AttributionStatus ]
Entity Type
Independent_Entity[ x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The AttributionStatus Entity contains terms that govern our understanding of the kind of attribution designated by a record in the Attribution entity. Typically the attribution status will default to "traditional" or "unquestioned" or perhaps to no value at all which will be taken to mean about the same. But there will be times when it will be important to characterize the nature of the attribution being documented. For instance if a well-known scholar rejects an important or traditional attribution it may be important to register that fact within an Attribution entity record and record that attribution as "rejected" and then tie the record back to a bibliography and citation entry. Below is a partial list of suitable terms taken from another project.
¦---------------------------------------¦
¦ (Undefined). ¦ ¦
¦ Verified. ¦ ¦
¦ Accepted. ¦ ¦
¦ Attributed to ¦ Disputed. ¦
¦ Ascribed to ¦ Questionable. ¦
¦ A guess."?" ¦ Dubious. ¦
¦ Traditional. ¦ Rejected. ¦
¦ Probable. ¦ Disproved. ¦
¦ Possible. ¦ Undecided. ¦
¦ Alternate. ¦ To be determined.¦
+---------------------------------------+
Structure:
There is a one-to-many relationship between AttributionStatus and the Attribution entity. One record in AttributionStatus may link to zero, one or many records in the Attribution entity. One record in the Attribution entity may link to zero or one record in AttributionStatus.
RULES:
An AttributionStatus record can only be linked to an Attribution record if either a PersonBio, Corporation or DateAttribution record is linked to Attribution.
An AttributionStatus record can only be edited if all the links to it are broken.
FIELDS:
AttributionStatusID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field manifests as a foreign key in the Attribution entity. In AttributionStatus AttributionStatusID is indexed for uniqueness.
AttribStatusTerm
This field identifies the kind of attribuiton intended by the linked items. See terminology in chart above. The values in this field must be indexed for uniqueness. It is suggested that as many terms that are needed to characterize an attribution be inserted in the AttributionStatus file.
AttribStatusMemo
This field provides the editor space in which to identify and define the term used in the corresponding AttribStatusTerm field.
]
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[ 4.60 ]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ DateAttribution ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[x ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The entity for recording object dates is attached to the Attribution record for reasons explained below. You will note that is is possible to attach more than a single date record to a single attribution record. This allows for multi-valued dates to be recorded -- as when work on a project or work takes place in multiple discrete intervals.
Some may find it peculiar that the object date entity is linked to the object through the Attribution entity. The reason for doing this is two-fold. First, dates of attribution are often the product of an opinion of authorship and so they belong with the author's attribution. When the author is anonymous, as for example in folk art or in ancient archaeological material, approximate dating criteria will come through the back door by way of the StylePeriodGroupMovement entity or through the NationalityCulture entity. But these indirect dates do not address the work as much as they supply chronological and/or stylistic context. So the second reason to use the portal of the Attribution entity is so that generically anonymous works can pass through the Attribution mechanism even when no individual or corporate body is linked to the attribution record. In such cases, still, the editor can link the attribution information of the date to a citation and a bibliographical entry.
Structure:
The DateAttribution entity is linked to the Attribution entity in a one-to-many relationship. Any record in the Attribution entity may be linked to zero, one or many instances of DateAttribution records. One DateAttribution record can be linked to no more than one Attribution record.
Rules:
DateAttribution records may not exist without being linked to a record in the Attribution entity. DateAttribution records MAY be edited while linked to Attribution entity records.
A date inserted in the field DateAttribEarly may not be chronologically later than a date inserted in the field DateAttribLate.
USAGE:
A useful tool is to process all dates B.C. (BCE) as negative integers. One useful convention is to use the suffix BC (or BCE) for all dates that have been interpreted into the BCE style -- since they are all applied and to continue the practice by using A.D. (CE) to identify all dates that also have been translated into modern notation. This means that when a date exists without an AD (CE) suffix, it is a modern date coming from our own dating calendar. To use this systematically means that an additional date field needs to be defined for non-calentrical notations, such as might use question marks to indicate guesswork or uncertainty.
Do not use DBMS dating fields for historical dates; use integer field types.
Fields:
DateAttributionID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does NOT manifest as a foreign key in the Attribution entity. In DateAttribution DateAttributionID is indexed for uniqueness.
AttributionID
This is the foreign key for AttributionID that manifests in the DateAttribution entity.
WorkItemID
This is a foreign key for the WorkItem entity that manifests in the DateAttribution entity. Theoretically it is possible to link a record in WorkItem to all dates associated with it without going through the Attribution entity. But doing so doesn't make sense since the Attribution entity is needed to interpret the meaning of dates registered in the DateAttribution entity. However, if only one DateAttribution record exists for a WorkItem record -- and this will be the most frequent case, then one can assume (with fair assurance) that the work of art is typically dated as given in that single DateAttribution record.
DateAttribEarlyDescriptor
DateAttribEarly
DateAttribEarlyCalendar
DateAttribLateDescriptor
DateAttribLate
DateAttribLateCalendar
These are the standard series of date fields as described for other date-bearing entities.
DateAttribNarrative
Because dates placed in the above date fields may have been translated to facilitate date queries, the DateAttribNarrative offers an opportunity to render a date in the manner in which it is usually given.
Note: that in the Attribution entity there is a field called AttribDateNarrative. The distinction between DateAttribNarrative and AttribDateNarrative is one of perspective. The former needs only consider dates in one record, whereas the latter must potentially render dates recorded in several linked records.
DateAttribNote
This field is used to explain any abnormality or special case that arises in the above system.
]
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[4.65]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ Corporation ]
Entity Type
Independent_Entity[x ] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The Corporation entity is based upon the Firms database in Susan William's Filemaker Pro template. The major difference between Firms and Corporation is that Corporation is designed to hold data on nearly any associating of individuals, be it a commercial firm, a monastic order, a guild or union -- in short, on any formal or informal group that may have some relation to a work of art.
Another major difference is the absence in the Corporation entity of a field in which to register the Corporation founder. This lack is made up by placing the founder's name into the PersonBio file and linking the corporation to it through a record in the CorporateIdentity entity. In fact any member of a corporation and his position within it can be registered in that way.
A third difference is in the lack of a field for a source citation. This lack is made up by using an AttribCitation record to link to the Bibliography entity.
Note: I have not (as yet) required that all data source materials be linked back to the bibliography -- but this change should be instituted whenever appropriate.
With the PersonBio entity the Corporation entity forms the two major sources for creator information. At this moment creator information may include collectors and others who have had a relationship to a work of art. We will also define an entity in which to record repositories. The VRA Core specifications require that the current repository be registered, with the accession number, if available. There is no reason, however, not to see the Corporation entity as an appropriate location for rendering the name of collecting institutions (repositories) and the Attribution entity as an appropriate location for entering any action in which a work of art participates. This change will be appropriate for a later incarnation of the AIC database and is in conformity with recommendations made by David Bearman (Archives and Museum Informatics) for the architecture of Museum Collection databases.
An aside: This database uses many linked files that spread out through several generations of linkages. Many works will not make use of these features, but some will, and it is not yet completely clear how much processing power will be necessary to make this kind of architecture run efficiently. Once this implementation is tested, it will be possible to determine whether additional features or new architectures can be integrated.
Structure:
The Corporation entity is directly connected to four other entities: Attribution, AttribCitation, CorporateRelation and CorporateIdentity. In each case one record in the Corporation entity may attach to more than one record in the attached entities, as follows:
1.The Corporation entity is linked to the Attribution entity in a one-to-many association. One record in the Corporation file may link to zero, one or many records in the Attribution file. This means that one Corporation may have multiple works associated with it. A single record in the Attribution file can only be linked to a single Corporation.
2.The Corporation entity is linked to the AttribCitation entity in a one-to-many relationship. One record in the Corporation file may link to zero, one or many records in the AttribCitation entity, each record of which may link to one Bibliography record.
3.The Corporation entity is linked to the CorporateRelation entity in what I call a "double one-to-many relationship." The CorporateRelation entity creates a pseudo-recursive relationship between records in the Corporation entity. (See the PersonRelation entity for a similar construction built next to the PersonBio file.) The CorporateRelationEntity contains two foreign key fields, each of which must link to a separate record in the Corporation entity. The purpose behind this is to be able to point to related corporate entities, such as successor corporations or to related firms and structures.
4.The Corporation entity is linked to the CorporateIdentity entity in a one-to-many relationship. One record in the Corporation file may have zero, one or many records in the CorporateIdentity file. One record in the CorporateIdentity file may link to one record in the Corporate file.
RULES:
The Corporation entity may optionally link to the Attribution entity, the AttribCitation entity, the CorporateRelation entity or the CorporateIdentity entity.
If there exists a link from the Corporation entity to a record in the Attribution entity, the Attribution entity record must link to a WorkItem record. If a link exists between the Corporate entity and any other entity, the CorpFormalName field in Corporation may not be edited. To edit the key identifying field (CorpFormalName) all links must be broken first.
If there exists a link from the Corporation entity to a record in the AttribCitation entity, there must be a link from that record to the Bibliography entity, and no other links in the AttribCitation entity but those two. The AttribCitation entity MAY be edited while linked to the Corporation and the Bibliography entities.
If there exists a link from the Corporation entity to the CorporateRelation entity there must exist two links to the CorporateRelation entity, with each link attached to a different record. The field CorporateRelationType in CorporateRelation is required.
If there exists a link from the Corporation entity to the CorporateIdentity entity there must also exist a link to the PersonBio entity. The CorpIdentityName field in CorporationIdentity is required.
In the Corporation entity the CorpFormalName field is required.
FIELDS:
CorporationID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does manifests as foreign keys in the Attribution entity (CorporationID), in the AttribCitation entity (CorporationID), in CorporateRelation twice (CorporationID and CorporationID/1), and in CorporateIdentity (CorporationID).
CorpDateEdited
CorpWhoEdited
These fields follow the standard format and rules for other ...DateEdited and ...WhoEdited fields.
CorpCountry
This field is equivalent to the NCTerm field in the NationalityCultureAuthority entity. It is listed here as a text field, but it should be the result of a lookup into the entity NationalityCultureAuthority. This field designates the original name of the country or geo-political entity in which the corporate body is most closely associated with.
CorpAssocNationality
This field is equivalent to the NCAssocNationality field in the NationalityCultureAuthority entity. It is listed here as a text field, but it should be the result of a lookup into the entityNationalityCultureAuthority.
CorpType
This is a controlled vocabulary field (perhaps fed through a linked authority file) that lists the kinds of firms or corporate bodies classified in the Corporation entity. The vocabulary list may begin with the one that Susan Williams compiled for the "Firm Type" field in her Firms database. Users should be able to query the database and sort by CorpType.
CorpDateEarlyDescriptor
CorpDateEarly
CorpDateEarlyCalendar
CorpDateLateDescriptor
CorpDateLate
CorpDateLateCalendar
These are the standard series of date fields as described for other date-bearing entities.
CorpNote
For misc. notes on the corporation entity, its history,etc.
CorpSortName
The name of the corporation beginning with a work that will make corporate entities sort appropriately and that will ease searches.
CorpFormalName
This is the formal name of the corporation. When the Corporation changes formal names, the editor has a choice of archiving the previous formal name, say in the CorpNote field or of creating a new record (linked through the CorporateRelation entity to the old record -- this is the preferable procedure.
]
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[4.70]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ CorporateRelation ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[x ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The CorporateRelation entity creates a pseudo-recursive relationship between records in the Corporation entity. (See the PersonRelation entity for a similar construction built next to the PersonBio file.) The CorporateRelation entity contains two foreign key fields, each of which must link to a separate record in the Corporation entity. The purpose behind this is to be able to point to related corporate entities, such as successor corporations or to related firms and structures.
Structure:
The Corporation entity is linked to the CorporateRelation entity in what I call a "double one-to-many relationship." The CorporateRelation entity creates a pseudo-recursive relationship between records in the Corporation entity. CorporateRelation contains two foreign keys that link to the Corporation entity: CorporationID and CorporationID/1. Use the CorporationID field to link to the superior or the initiating record and CorporationID/1 to link to the inferior or the closing record. Which is which will frequently depend upon the terminology used in the CorporateRelationType field. A standard set of vocabularies for this field should be established so that there are not multiple crossing references: i.e. A is father to B and B is son to A.
RULES:
If there exists a link from the Corporation entity to the CorporateRelation entity there must exist two links to the CorporateRelation entity, with each link attached to a different record. The field CorporateRelationType in CorporateRelation is required. (See above for usage suggestions.)
FIELDS:
CorporateRelationID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does not manifest as a foreign key.
CorporationID
CorporationID/1
The above two fields are the double foreign keys linking to the Corporation entity. See discussion of their use, above.
CorpRelationType
This field is used to explain the nature of the relationship between the record linked through CorporationID and CorporationID/1. It should use a controlled vocabulary the terms of which will best be determined through usage.
CorpRelationNote
A field in which to enter explanations or usage notes regarding the field CorpRelationType
]
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[4.75]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ CorporateIdentity ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[x ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The CorporateIdentity entity serves to establish relationships between Corporation entity records and PersonBio entity records. It permits individuals classified in the PersonBio entity to be attached to one or more Corporations, and similarly, permits individual Corporations to be attached to one or more individuals in PersonBio.
The CorporateIdentity entity allows the nature of the relationship between PersonBio and Corporation to be specified in the field CorporateIdentityName.
Structure:
The CorporateIdentity entity is linked to the Corporation entity in a one-to-many relationship. One record in the Corporation entity may link to zero, one or more records in CorporateIdentity. One record of the entity CorporateIdentity may link to only one record in CorporateIdentity.
The CoroprateIdentity entity is linked to the PersonBio entity in a one-to-many relationship. One record in the PersonBio entity may link to zero, one or more records in CorporateIdentity. One record of the entity CorporateIdentity may link to only one record in CorporateIdentity.
Rules:
A record in CorporateIdentity must be linked to the Corporation entity and to the PersonBio entity.
A record in CorporateIdentity MAY be edited while it is linked.
Records linked to a CorporateIdentity entity cannot be deleted until the CorporateIdentity link is deleted.
Usage:
There should be an optional list of authorized terminology that serves to structure the contents of the CorIdentityName field.
Fields:
CorporateIdentityID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does NOT manifest as a foreign key.
CorporationID
This is the foreign key that links the CorporateIdentity entity to the Corporation entity.
PersonBioID
This is the foreign key that links the CorporateIdentity entity to the PersonBio entity.
CorpIdentityName
This field is used to explain the nature of the relationship between the record linked through CorporationID and PersonBioID. It should use a controlled vocabulary the terms of which will best be determined through usage.
CorpIdentityNote
A field in which to enter explanations or usage notes regarding the field CorpIdentityName.
]
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[4.80]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ AttribCitation ]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ x] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The AttribCitation entity serves as the means of establishing a many-to-many relationship between the Bibliography entity (still undefined) and several authority lists and attribution entities. Its purpose is to place all references used to document the database into a single Bibliography File, while providing a means of linking the specific citation needed by the attribution and authority entities with the general reference appropriate to a bibliography. Naturally, a query by bibliographic entry into the AttribCitation file will show where that item has been used as a source or reference.
Earlier ER diagrams in this series have defined "citation" entities. Looking back, these should be integrated into this sing citation entity and the name "Attrib.." should be removed. (That's for a later revision.)
In the present ER diagram the AttribCitation entity is linked to numerous files, all of which use AttribCitation to establish many-to-many relationships to the Bibliography entity.
Structure:
The AttribCitation entity is linked to the following entities: NationalityCulture, StylePeriodGroupMovement, Attribution, Corporation, PersonBio and Bibliography.
1.There is a one-to-many relationship between AttribCitation and NationalityCulture. A single record in the NationalityCulture entity can link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation can link to zero or one instance of Nationality Culture.
2.There is a one-to-many relationship between AttribCitation and StylePeriodGroupMovement. A single record in the StylePeriodGroupMovement entity can link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation can link to zero or one instance of StylePeriodGroupMovement.
3.There is a one-to-many relationship between AttribCitation and Attribution. A single record in the Attribution entity can link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation can link to zero or one instance of Attribution.
4.There is a one-to-many relationship between AttribCitation and the Corporation entity. A single record in the Corporation entity can link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation can link to zero or one instance of Corporation.
5.There is a one-to-many relationship between AttribCitation and the PersonBio entity. A single record in the PersonBio entity can link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation can link to zero or one instance of PersonBio.
6.There is a one-to-many relationship between AttribCitation and the Bibliography entity. A single record in the Bibliography entity may link to zero, one or multiple instances of citations in AttribCitation. One instance of AttribCitation MUST link to one instance of Bibliography. (Each instance of the AttribCitation entity MUST link to a Bibliography record.)
RULES:
1.An AttribCitation record cannot exist unlinked to a Bibliography entry. This means that the Bibliography entry must be made prior to an AttribCitation record.
2.An AttribCitation entity can have no more or no less than two links per record: 1) The Bibliography record and 2) one of the following: Corporation, Attribution, StylePeriodGroupMovement, NationalityCulture or PersonBio.
3.None of the files linked to an AttribCitation record may be deleted if there is an AttribCitation record linked to it. It will be necessary to delete the AttribCitation record first.
FIELDS:
AttribCitationID
This is the primary key field. Its values are unique to each record. Deleted records retire the value of the primary field. New values are added sequentially. This field does NOT manifests as a foreign key.
AttributionID
The above field is a foreign key from the Attribution entity.
StylePeriodGroupMovementID
The above field is a Foreign Key from the StylePeriodGroupMovement entity.
WorkItemID
The above field is a foreign key from the WorkItem entity. The WorkItem entity is placed in the AttribCitation entity automatically by VISIO because all citations eventually link back to specific WorkItem records. If the WorkItemID field can be filled automatically through loookups it might provide a bibliographic service of use.
WorkItemID/1
WorkItemID/2
This foreign key looking back to the WorkItem entity was placed automatically by VISIO. I don't understand the path that leans from the WorkItem entity to this manifestation of its primary key.
PersonBioID
This is a foreign key from the PersonBio entity.
AttribCitationReference
This field is used to record the precise reference that leads from the information reproduced to the bibliographic item. Its use is optional when the precise citation is obvious. Its form should follow a standard citation syntax, but that is not necessary. This field is not indexed.
AttribWhoMadeIt
The bibliographic citation of an attribution does not always include or point to the name of the person who is responsible for the attribution. That person may be a third party in the cited book. In all cases when an attribution, be it an attribution of date, culture, maker, etc. points to an individual as its author, the name of that individual should be entered into this field. The names of attributors should conform to a list of controlled names. This list has not been created for this implementation.
CitationType
This field is reserved for a future scheme with which to classify types of citations. It may be used, for example to identify the source as a conversation, webpage, lecture, video, book, scholarly journal, etc. More probably these "types" belong in the bibliographic records.
BibliographyID
This is the foreign key that links to the Bibliography entity. This field must be used for all AttribCitation records.
NationalityCultureID
This is the foreign key that links to the NationalityCulture entity.
CorporationID
This is the foreign key that links to the CorporationID field.
]
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[4.85]
DIAGRAM_NAME[ Attribution ]
Entity_Name[ Bibliography ]
Entity Type
Independent_Entity[ x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ -
The Bibliography entity accumulates all references to information outside of the database. It is used in the Concordance section (Diagram 00) to identify textbooks. It is used to cite references to sources for controlled vocabulary and for attributions.
The entity has not yet been defined.
]
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[ ]