Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.00]
DIAGRAM_NAME[Work Relations]
Diagram Description[ --
NOTES and COMMENTS entity:
The Diagram "Work Relations" contains two structures. The first of these is for user, contributor and staff comments relative to the work of art (WorkItem entity) to which the record in "WorkItemComments" is attached. This mechanism uses a complex of four entities, in total. The main entity, "WorkItemComments," is potentially linked to the Bibliography file in case the comments need to be documented by a biographical listing. A field in which to record the exact bibliographic citation is included. The WorkItemComments entity is also linked to the PersonBio file in case the commentator is to be listed among the set of searchable names. In general it is advisable to document all accepted comments by using the Bibliographic and the PersonBio entities. And, of course, WorkItemComments is linked to the WorkItem entity.
The "WorkItemComments" entity fulfulls the VRA Core category W19: Notes.
Each Comment is given a record status value, which should default to a value equivalent to "provisional" or "presented for acceptance:. AIC editors have the option not to accept every comment and may even return comments to their authors for further work. Comments are treated like small publications. Authors must acknowledge that they are offering their copyright to us non-exclusively. Only records so offered can be transmitted to the editors.
RELATED WORKS ENTITY:
The second structure in the WorkRelations permits our editors to create chains and other relational structures among catalogued works. It fulfills the VRA Core (ver 2.0) categories of W17 and W18: Related Work and Relationship Type.
Architecture
The database architecture used to accomplish this function is a variant on a database recursive structure. To create a record for a "related work" an individual work in the entity WorkItem (the main entity for catalogued works) is made to relate to another work in the same entity. (The entity is, therefore related to itself.) This "recursive" structure is achieved in an unorthodox manner by creating an entity called WorkItemRelation. It is the WorkItemRelation structure that is used to define HOW any given work is related to another.
WorkItemRelation contains two fields that can connect to records in the WorkItem entity. Both fields are foreign keys to WorkItemID, the primary field in the WorkItem entity. The first of these fields in the WorkItemRelation entity will be used to establish a connection to the "dominent" work in the connection. The work connected to this field can be considered analogous to the subject of an active sentence. It acts. The work linked to the second foreign key in WorkItemRelation can be likened to an object of a sentence: it is acted upon. Thus we can create a relationship that states that "Work One" is a copy of [i.e. "copies"] "Work Two." I'll call this second position "subordonate." If we wish to express the reciprocal connection which says that "Work Two" is the prototype of (or the source for) "Work One" the works would have to be linked in the opposite order.
Reciprocal relationships
The CDWA and VRA standards request that reciprocal relationships should be applied automatically, but, unfortunately it is the nature of language that terms that establish the reciprocal relationship do not always imply a reverse relationship, so, when links between two works are created, editors should be careful that the link actually implies the nature of the intended relationship.
Syntactical structures
All all relationships between two works use this item-to-item architecture. But when the architecture implicates more than two works, several different structures can be defined, that is, there are different syntactical structures that can be built with this "annotated" recursive device. The nature of these structures can be defined in the shape of the set of relationships. Unfortunately (or rather, fortunately) the nature of humanities studies makes it impossible to define every conceivable type of structure. While the notion of imposing what amounts to a schematic on top of related sets of works may be odious to some, the system can often prove quite useful.
For the purposes of this database -- somewhat experimentally -- I have created two ways to define the way objects link together. The first of these attempts to name either the shape of the structure or the function of the relationship -- without defining the precise relationship.
The first set of terminologies is stored in the entity "WorkItemRelationStructure." The second is held in the entity called "WorkItemRelationTypeAuthority."
"WorkItemRelationStructure" will either tell the user what the set of bonds (links) between a set of objects is supposed to look like or how it functions. Here is the set I've defined thus far: Sequential, Parallel, Hierarchical, Associative, Pedagogical and Sets. They are defined as follows:
A Sequential relationship links objects in a chain relationship. The first object is connected to the second and the second to the third, etc. Sequential relationships may be used to identify a series of works that are to be presented in order -- such as in date order, or, more usefully, perhaps, in the order of a given cycle, or in the order in which illustrations appear - as in a book. This formula may be overused easily. Restraint is suggested. For example, while theoretically it may be possible to link all the works of an artist into a chain replicating their order of creation, the function served will be temporary at best, is already served by a dating mechanism, and easily can overburden the resources of the database management services.
A Parallel relationship identifies a group of works that belong together but which for a variety of reasons is not suited to be arranged in sequence. For example a cluster of works, associated with each other may be connected in this way. For a parallel or group relationship it may be necessary do define one record to serve as the parent, with the others taking the place of child records. One may create in this way a placeholder group record, as for example, a destroyed pediment of a temple from which only individual pieces of sculpture remain. Or one may use this device to unite all the studies and drawings related to a given finished work.
A Set relationship is a special case of a Parallel relationship. In a set all the pieces come together to form a whole of a single work. Parallel relationships do not require that the members of the parallel set form parts of a single item. Perhaps more useful for a museum object database, defining a "set" permits all items in a tea set to be united or pieces of a chess set. A set may include all items in a portfolio prints.
A Hierarchical relationship indicates that the depth of relations may surpass two. A single record serves as the parent of a child record, which, in turn, is the parent of another child. Theoretically editors can build hierarchical relations that bring in all elements of a Gothic Cathedral and divide them into hierarchial units, or all panels in a large altarpiece. Altarpiece panels need not be together to be united by a "WorkItemRelation".
A Single relationship connects two works only. It goes from one item to another and no further. All complex relationships are compose of groups of singles, but the term "Single" is to be used when only two and no more than two items are connected. The word single should be interpreted as having less significance that the terms "associative" and "pedagogical," defined below.
In addition to the above "structural" relationships, I've defined two types of relations that are based on content. These, of course, can be built up as parallel or even hierarchical structures, but it seems proper to define these by their use:
The first of these I call Associative. Associative records may at times be equivalent to those built upon a Parallel relationship -- structurally -- but may include a wide variety of works such as plans, versions, drawings after, documents related to, works derived from, etc. The Cardosso medal showing Bramante's Design for St. Peter's Cathedral can be defined as associative.
The second forms a class of images can best be labeled Pedagogical. These may include reconstruction drawings, plans and diagrams, elevations and mostly modern drawings or presentations of older monuments. Models made for teaching fit in here, too.
The above terms (and perhaps others) are kept an a small authority file called WorkItemRelationStructure. The purpose of tagging the WorkItemRelation record with one of these terms is to give the user some indication of what kind of relationship to expect to find uniting the two current works: the original and the related work. There is no required association made between the terms cited above and those that are collected in the entity called WorkItemRelationTypeAuthority.
In WorkItemRelationTypeAuthority keep track of the terms that actually define the nature of the specified relation between two works: To repeat the terms used in the CDWA and the VRA core they may include (with additions), among others: part of, larger context for, prepatory sketch of, cartoon for, model, for, modello for, study for, plan for, printing of, copy after, derived from, probably a prototype for, predella of, etc. This is an authority file and should be used to build up a set of real-world terminology. There is no obligation at this time to keep track of the "type" of relationship implied by the use of any of these terms. That may be a project for another day.
VIEWS entity
These terms should be used to describe any two items that are separate works of art and are related. If there are images that are separate views of the same work, these descriptions should be entered into the "Views" entity. For instance, photographs of the rear of a panel or a detail of a sculpture, etc. are actually different views of the same object. But if one photograph represents the south porch of a Gothic cathedral, and another shows one of the flanking sculptures in that structure, these are separate works and may be related using the "Relationship Type" facility.
Multiple Relationships
Clearly, it is possible for any single work to take part in more than a single relationship. One work may be part of a hierarchy at the same time it is included in a group of studies and documents. How is the user going to trace all the potential threads that eminate from the WorkItemID field?
The WorkItemRelationCatalogue
To clarify which group of objects belonging to a relationship belong together, each relationship that includes more than two items (subject to revision) should be catalogued. The entity WorkItemRelationCatalogue offers a means by which any group of works can be tied together under a single name. This way the investigator can follow the named threads to uncover disperate works that have been linked together. The catalogue can also be used as an access point; the investigator can query for all works that belong to a single group, and from there proceed to the objects.
Caution
Naturally, defining multidudes of relationships can become a tedious andconfusing task and can overburden a database with too many related records. Object relations should be created with discretion and should be created by trained experts.
Usage and Operational Issues
The kind of display structure described for use of the recursive entity TextChapterHead (Diagram 00) cannot be employed here. More specifically, when more than a single WorkItemRelation record is linked to a work in the entity WorkItem, the user should be shown a display divided into two parts. One part will list those records linked to the WorkItemID foreign key in WorkItemRelation and the other part will list those records linked to the WorkItemID/1 foreign key in WorkItemRecord. In other words for any record in WorkItem, the work specified may serve as either the "subject" of a relation or the "object" or "predicate" of the relation. Further, there may be more than one instance in which the work in WorkItem serves as both subject and predicate. From a hierarchical point of view one might say that any single record can have multiple parentage and multiple children. These will include all kinds of relationships.
If, however, a single catalogue value (from WorkItemRelationCatalogue) is chosen, and the structure is identified as hierarchical, then the resulting structure should be required to obey standard rules for hierarchical structures -- namely single parentage. In such a case the display function should be able to coinside with the kind of hierarchical upward display and the kind of sibling downward display defined for the TextChapterHead entity in Diagram 00.
Obviously the record display mechanism will have to be sensitive to whether a single value has been chosen from the WorkItemRelationCatalogue entity to limit the number of WorkItemRelation records discovered.
With X as the current record from WorkItem and no specified value from the Catalogue, I envision a display that looks somewhat like the following:
Hierarchical displays will appear in two modes: upward and downward.
The These displays can be combined into a single report, as follows. H being the current record.
The same can be rendered with indentation, as follows:
This structure I adapted from the display of the Getty Thesaurus of Geographic Names (TGN) at http://shiva.pub.getty.edu/tgn_browser/
Bibliography and Citations:
Without doubt the kinds of assertions that constitue a WorkItemRelations record may often result from critical and scholarly opinion. It is therefore necessary to offer the cataloguer and editor opportunity to document the source of such assertions. A Citation entity will link such assertions to the Bibliography entity.
A word about using citations. Most of the information that will be coded into the files describing works of art will be presented as common knowledge or as indisputable fact (even when it is the result of the individual or accumulated opinions of historians and experts). In these cases it will be almost impossible -- and probably not to be recommended -- to trace such works down to their sources. When identifications and attributions seem peculiar or new or derived from very old volumes, it may be advisable to enter their sources into the bibliography files. Whenever an image is in dispute -- as for instance happens frequently with works by Rembrandt and other old masters, then, too, whenever possible such information should be tracked to its source.
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.05]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItem]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
The WorkItem entity is the central entity that defines the work of art in the database. The WorkItemID is the database catalogue number for the work of art catalogued.
It is represented here in abbreviated format, showing only those relating entites pertinent to the present diagram.
Structure and Rules:
In the Work Relations diagram WorkItem is connected to two entities: WorkItemComments and WorkItemRelation.
1.WorkItemComments is related to WorkItem in a one-to-many relationship. One instance of WorkItem may be related to zero, one or many instances of WorkItemComments. Every instance of WorkItemComments must be connected when stored to an instance of WorkItem.
2.The entity WorkItemRelation is twice related to the WorkItem entity. This structure creates a recursive-type relation to WorkItem whereby a record in WorkItem can be connected to a record in WorkItemRelation which, in turn, can be connected back to a record in the WorkItem entity.
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.10]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemComments]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[ ] or
Associative_Entity[x] or
Subset_Entity[ ]
Entity_Description[ --
The WorkItemComments entity is for user, contributor and staff comments relative to the work of art (WorkItem entity) to which the record in "WorkItemComments" is attached. This mechanism uses a complex of four entities, in total. The main entity, "WorkItemComments," is potentially linked to the Bibliography file in case the comments need to be documented by a biographical listing. A field in which to record the exact bibliographic citation is included. The WorkItemComments entity is also linked to the PersonBio file in case the commentator is to be listed among the set of searchable names. In general it is advisable to document all accepted comments by using the Bibliographic and the PersonBio entities. And, of course, WorkItemComments is linked to the WorkItem entity.
The "WorkItemComments" entity fulfulls the VRA Core category W19: Notes.
Each Comment is given a record status value, which should default to a value equivalent to "provisional" or "presented for acceptance:. AIC editors have the option not to accept every comment and may even return comments to their authors for further work. Comments are treated like small publications. Authors must acknowledge that they are offering their copyright to us non-exclusively. Only records so offered can be transmitted to the editors. Short excerpts from pubished works that pertain to the WorkItem may be quoted if it is considered consistant with fair use quotation practice.
Structure and Rules:
The WorkItemComments entity is connected to three other entities: WorkItem (see above), Bibliography and PersonBio. The Bibliography entity keeps track of sources for data used in the database. It is not yet designed and will wait for implementation later. The PersonBio entity (see Attribution Diagram, number 03A) keeps track of the names of people and their relevant biographical informaiton.
1.The WorkItemComments entity is related to the WorkItem entity in a one-to-many relationship: One instance of WorkItem may be related to zero, one or many instances of WorkItemComments. Every instance of WorkItemComments must be connected when stored to an instance of WorkItem.
2.The WorkItemComments entity is related to the Bibliography entity in a one-to-many relationship: One instance of WorkItemComments may relate to one instance within Bibliography. One instance in Bibliography may relate to zero, one or many instances of WorkItemComments.
3.The WorkItemComments entity is related to the PersonBio entity in a one-to-many relationship: One instance of WorkItemComments may relate to one instance within PersonBio. One instance in PersonBio may relate to zero, one or many instances of WorkItemComments.
Fields:
WorkItemCommentsID
This is the primary field for the WorkItemComments entity. Each value is unique. Old values are deleted and are not replaced. The values of NationalityCultureID are assigned sequentially. This field is not linked to any other entity. It is only used to name each instance uniquely.
WorkItemID
This is the foreign key that corresponds with WorkItemID in the WorkItem entity. It is used to connect WorkItem and WorkItemComments in a one-to-many relationship. Values in WorkItemID within WorkItemComments may repeat.
BibliographyID
This is the foreign key that corresponds with BibliographyID in the Bibliography entity. It is used to connect WorkItemComments and Bibliography in a one-to-many relationship. Values in BibliographyID within WorkItemComments may repeat.
PersonBioID
This is the foreign key that corresponds with PersonBioID in the PersonBio entity. It is used to connect WorkItemComments and PersonBio in a one-to-many relationship. Values in BibliographyID within WorkItemComments may repeat.
WorkItemCommentAuthor
This is a text field used to record the name of the author of the text comment. Representing the author's name is important when a bibliographic link points to an item not written by the author of the comment or for when no link to either the Bibliography or the PersonBio entities are created.
WorkItemCommentDate
This date field is used to record the date on which the comment was first submitted. It is different from most entity date created fields because it reocrds the first rather than the last date.
WorkItemComment
This field, a MEMO field is used to record the comments submitted. It has been suggested that submissions and comments provided by scholars may at some time be accepted as professional level work suitable to be considered for advancement, retension and tenure.
WorkItemCommentEDITORNote
This field is used to record notes of the AIC editor relative to the comments submitted.
WorkItemCommentRecordStatus
This field is used to record the status of the record and comments. All initial values in this field should default to something like: unedited. Only records with approved values should be displayable to the public.
WorkItemCommentBibliographicCitation
This field is used to indicate the exact location within any Bibliographic item linked (via the Bibliography Entity)to the WorkItemComments entity.
]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.15]
DIAGRAM_NAME[Work Relations]
Entity_Name[Bibliography]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
The Bibliography entity is connected in this diagram to the WorkItemComments entity. Comments may be linked to bibliographic entries. See further, the description of the WorkItemComments entity, above.
Structure:
The Bibliography entity is related to the WorkItemComments entity in a one-to-many relationship. One instance of Bibliography may be linked to zero, one or many instances in WorkItemComments. One instance in WorkItemComments may be linked to one instance of Bibliography.
]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.20]
DIAGRAM_NAME[Work Relations]
Entity_Name[PersonBio]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
The PersonBio entity is connected in this diagram to the WorkItemComments entity. Comments may be linked to entries in the PersonBio entity. See further, the description of the WorkItemComments entity, above.
Structure:
The PersonBio entity is related to the WorkItemComments entity in a one-to-many relationship. One instance of PersonBio may be linked to zero, one or many instances in WorkItemComments. One instance in WorkItemComments may be linked to one instance of PersonBio.
]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.25]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemRelation]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[x] or
Subset_Entity[ ]
Entity_Description[ --
The WorkItemRelation entity establishes the nature of the connection between two separate works in the WorkItem entity. See discussion of this process in record sortorder 6.00.
Any work in WorkItem may be related to other works in WorkItem in a variety of ways. If a relationship is established between two works, nothing forbids these works from belonging concurrently to other sets and to other structures of relationships.
The WorkItemRelation entity contains links to three authority files. One of these helps identify the kinds or structures of relationships to which the link belongs, and the other provides the precise terminology used to define the relationship between two works. In addition, any extended set that includes more than two works, and any set that uses a multi-level hierarchy, can and should be named as a settherefore joining all members of that set through that name. The name, a catalogue entry, is kept in the WorkItemRelationCatalogue entity.
No suggestion is being made here to establish usage conventions for these catalogue entries, but it is hoped that with some practice, an efficient form of naming convention that eases searches will evolve. Users are advised to consult other naming authorities for help, perhaps including the LC Subject Heading List as a guide.
To achieve its purpose the WorkItemRelation entity must have two locations with which to establish links to the WorkItem entity. Because works are related to each other in mostly un-equal ways, it is necessary to define one of the two foreign keys in WorkItemRelation as "dominant" and the other as "subordonate." This convention will permit a relation to say, in effect, that Work A is a copy of Work B. Or Work A represents a larger context in which work B plays a part (i.e. whole/part relation).
Structure and Rules:
The entity WorkItemRelation is connected to five other entities: WorkItem (twice), WorkItemRelationStructure, WorkItemRelationTypeAuthority, WorkItemRelationCatalogue and WorkItemRelationCitation.
1.WorkItemRelation is connected to WorkItem with a "double" one-to-many relation. There are two fields in WorkItemRelation that must be linked to WorkItem. Each of these fields must be linked to a separate record in the WorkItem table.
2.WorkItemRelation is connected to WorkItemRelationStructure in a one-to-many relation. One record in WorkItemRelation must be connected to one record in WorkItemRelationStructure. One record in WorkItemRelationStructure may be related to zero, one, or more records of WorkItemRelation. A connection from WorkItemRelation to WorkItemRelationStructure is required.
3.WorkItemRelation is connected to WorkItemRelationTypeAuthority in a one-to-many relation. One record in WorkItemRelation must be connected to one record in WorkItemRelationTypeAuthority. One record in WorkItemRelationTypeAuthority may be connected to zero, one or many records in WorkItemRelation. A connection from WorkItemRelation to WorkItemRelationAuthority is required.
4.WorkItemRelation is connected to WorkItemRelationCatalogue in a one-to-many relation. One record in WorkItemRelation may be connected to zero or one record in WorkItemRelationCatalogue. One record in WorkItemRelationCatalogue will usually be connected to two or more records in WorkItemRelation. The purpose of WorkItemRelationCatalogue is to characterize a set of records in WorkItemRelation. This is not necessary if only one such record exists to define an object relation.
5.WorkItemRelation is connected to WorkItemRelationCitation in a one-to-many relation. One record in WorkItemRelation may be connected to zero, one or many records in WorkItemCitation. A record in WorkItemCitation must connect to one record in WorkItemRelation. The link from WorkItemRelation to WorkItemCitation is not required, but if a WorkItemRelationCitation record exists, it must be linked (when stored) to a record in WorkItemRelation -- as well as to a record in the Bibliography entity.
When stored, the WorkItemRelation record must be linked to two records in WorkItem, to one record in WorkItemRelationTypeAuthority, to one record in WorkItemRelationStructure. It may be linked to one record in WorkItemRelationCatalogue.
Caution: A WorkItemRelation Record cannot be linked to the same work twice. Two works may not be linked multiple times through identical butseparate records in the WorkItemRelation entity. In other words you may not have repeating connections as follows:
Fields:
WorkItemRelationID
This is the primary key. It is created sequentially, numbers for deleted records are retired. It is not used as a foreign key in any other entity.
WorkItemID
WorkItemID/1
These are the two foreign keys in WorkItemRelation that connect to the WorkItem entity. The WorkItemID field represents the link to the "dominent" record in the expressed relationship; the WorkItemID/1 field represents the link to the "subordenate" record in the expressed relationship. Thus if we are using a WorkItemRelation record to state that "Work 1 is based upon Work 2", then Work 1, in the WorkItem entity, will be linked to field WorkItemID in WorkItemRelation and Work 2 in the WorkItem entity will be linked to the field WorkItemID/1 in the WorkItemRelation entity. Note that a reciprical relationship expressed as follows: "Work 3 is the source for Work 4" requires that Work 3 holds the same logical realation to WorkItemID as before. It is the structure of the statement connecting the two works that determines where each work is linked, and that structure is determined by the terminology chosen from the file WorkItemRelationTypeAuthority. In my opinion it is better that the relationships follow natural language than some abstract scheme that forces application of altered versions of natural language.
WorkItemRelationStructureID
This field links to the WorkItemRelationStructure entity that is to be used to classify the kind of WorkItemRelation set that is being built. The terms to be applied here have been discussed in record 6.00 at the beginning of the description for this diagram. They consist of the following terms: Sequential, Parallel, Set, Hierarchical and Single. In addition, two non-structural terms may be employed: Associative and Pedagogical. These latter two will, most likely, be variants of the parallel structure defined above. In hierarchical arrangements parallel structures create sibling relationships, however by themselves they simply groups a set of works that are useful to gather together. One way to create this kind of parallel structure is to define a hypothetical parent, for instance, "Egyptian works taken by Napoleon to France." This concept may be difficult register any other way except by grouping -- though the provenance utility may work. It is important to realize that the AIC database offers many ways to group works, i.e. by original location, by collector, by attribution, and many others. Using the AIC regular tools should be preferred to using the object relation utility.
The contents of this field does not control how records are to be related to each other. It should be possible to build one structure and name it wrongly. The values inserted here are only intended to serve as guides to the user who may need to know in what kind of structure he is working.
WorkItemRelationTypeAuthorityID
The WorkItemRelationTypeAuthorityID field connects to the WorkItemRelationTypeAuthority entity. This structure is used to keep the set of authorized terms that relate two works of art. The CDWA and the VRA core recommendations offer examples that answer this question: "What is the relationship between the Related Work and the described work?" In the VRA model there is an implied distinction between "a related work" and a "described work" and we follow that distinction with the exception that either work may be a "related" or a "described" work depending upon the context. Refer to the VRA core categories (ver 2.0) for relevent examples.
WorkItemRelationCatalogueID
The WorkItemRelationCatalogueID field connects to the WorkItemRelationCatalogue entity. This structure is used to keep the names of defined groups that are made up of three works or more. (There is no reason to name groups of two -- though it is not impossible to do that.) Use of the Catalogue term is optional but will clarify and help coalesce complex multifarious groupings.
WorkItemRelationWhoAssigned
The name of the person who created or last edited this record. Ideally this value should be taken from an authority file of names and information about editors.
WorkItemRelationWhenAssigned
The last date on which the WorkLocationWhoAssigned field was edited.
WorkItemRelationRecordStatus
The administrative status condition of the record. It may be marked as unedited, unapproved, provisional, needs research, etc. There should be an authority file that controls the terms used.
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.30]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemRelationStructure]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
The WorkItemRelationStructure entity is used to classify the kind of WorkItemRelation set that is being built. The terms to be applied here have been discussed in record 6.00 at the beginning of the description for this diagram. They consist of the following terms: Sequential, Parallel, Set, Hierarchical and Single. In addition, two non-structural terms may be employed: Associative and Pedagogical. These latter two will, most likely, be variants of the parallel structure defined above. In hierarchical arrangements parallel structures create sibling relationships, however by themselves they simply groups a set of works that are useful to gather together. One way to create this kind of parallel structure is to define a hypothetical parent, for instance, "Egyptian works taken by Napoleon to France," or "Works related to the Sistine Ceiling." This concept may be difficult register any other way except by grouping -- though the provenance utility may work for the Napoleon example. It is important to realize that the AIC database offers many ways to group works, i.e. by original location, by collector, by attribution, and many others. Using the AIC regular tools should be preferred whenever possible to using the object relation utility.
The contents of this field does not control how records are to be related to each other. It should be possible to build one structure and name it wrongly. The values inserted here are only intended to serve as guides to the user who may need to know in what kind of structure he is working.
Structure and Rules:
The WorkItemRelationStructure entity is connected to the WorkItemRelation entity in a one-to-many relation. One record in WorkItemRelationStructure may be linked to zero, one or many records in WorkItemRelation. One record in the WorkItemRelation entity must be linked to a record in the WorkItemRelationStructure entity.
Fields:
WorkItemRelationStructureID
This field is the key field in the WorkItemRelationStructure entity. It is assigned serially. Values for deletet terms are retired. It appears as a foreign key in the WorkItemRelation entity.
WorkItemRelationStructureTERM
This text field is used to record the relation "structure" value that is to be used to typify each qualifying relation. Suggested values are as follows: sequential, parallel, set, hierarchical, single, associative and pedagogical.
WorkItemRelationStructureNOTE
This MEMO field is used to describe and define how the WorkItemRelationStructureTERM is used. It is a scope note that provides help for future editors and cataloguers.
WorkItemRelationStructureWHOAssigned
This is a field that is automatically filled in with the moniker of the editor signed onto the system who last changed or created the value of the WorkItemRelationStructureTERM.
WorkItemRelationStructureWHENAssigned
This date field is automatically filled in with the system date when the value in WorkItemRelationWHOAssigned is first created or updated.
WorkItemRelationStructureRECORDStatus
This field is used to record the administrative level of completeness of the WorkItemRelationStructure record. The terms should follow those designed for similar *RecordStatus fields in this database.
-]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.35]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemRelationTypeAuthority]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
The WorkItemRelationTypeAuthority entity is used to keep the set of authorized terms that relate two works of art. The CDWA and the VRA core recommendations offer examples that answer this question: "What is the relationship between the Related Work and the described work?" In the VRA model there is an implied distinction between "a related work" and a "described work" and we follow that distinction with the exception that either work (any work) may be a "related" or a "described" work depending upon the context. Refer to the VRA core categories (ver 2.0) for relevent examples. In our usage, The "described" work is linked to the foreign key WorkItemID in the WorkItemRelation entity while the "related" work is linked to the foreign key WorkItemID/1 in the WorkItemRelation entity. (See sortorder 6.00 for an extended description of this device.)
In short, the "Described Work" will always be the subject of an active sentence and the "Related Work" will be the object of an active sentence. (Work A copies Work B) Passive sentence constructions should be avoided: (Work C is copied by Work D). In this passive construction it might appear to some that Work C is the "Described Work" and Work D is the "Related Work" when the situation is actually the opposite.
The terms held in this entity are not schematic; they are derived from the literature of art and should reflect the terminology used by historians and critics. At the same time, many of these terms are catalogued in the AAT, a source that may be mined to build up a useful catalogue of terms of relationship.
Usage: [to be added later.]
Structure and Rules:
The entity WorkItemRelationTypeAuthority is linked to the WorkItemRelation entity in a one-to-many relationship. One instance of WorkItemRelationTypeAuthority may be linked to zero, one or many instances of WorkItemRelation. One instance of WorkItemRelation must be linked to one instance of WorkItemRelationTypeAuthority. The terms in WorkItemRelationTypeAuthority should be unique. Passive constructions should be turned into their active equivalents.
Fields:
WorkItemRelationTypeAuthorityID
The WorkItemRelationTypeAuthorityID field is the primary key field in the entity. Its values are assigned serially and values from deleted records are retired. This field manifests as a foreign key in the WorkItemRelation entity.
WorkItemRelationTypeTerm
This field is used to record the terms of relationship that will specify how two works are connected, linked or related. The terminology, according to the VRA Core Standards should be taken from the AAT (among other sources), especially the "Information Forms" and "Visual Works" hierarchies. Also suggested is the "Library of Congress Descriptive Terms for Graphic Materials" and "Revised Nomenclature."
WorkItemRelationTypeTermRecordStatus
This field is used to record the administrative level of completeness of the WorkItemRelationTypeAuthority record. The terms should follow those designed for similar *RecordStatus fields in this database.
WorkItemRelationTypeNOTE
This MEMO field is used to describe and define how the WorkItemRelationTypeTerm is used. It is a scope note that provides help for future editors and cataloguers.
WorkItemRelationTypeWHOAssigned
This is a field that is automatically filled in with the moniker of the editor signed onto the system who last changed or created the value of the WorkItemRelationTypeAuthority record.
WorkItemRelationTypeWHENAssigned
This date field is automatically filled in with the system date when the value in WorkItemRelationTypeWHOAssigned is first created or updated.
-]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.40]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemRelationCatalogue]
Entity Type
Independent_Entity[x] or
Dependent_Entity[ ] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
To clarify which group of objects belonging to a relationship belong together, each relationship that includes more than two items (subject to revision) should be catalogued. The entity WorkItemRelationCatalogue offers a means by which any group of works can be tied together under a single name. This way the investigator can follow the named threads to uncover disperate works that have been linked together. The catalogue can also be used as an access point; the investigator can query for all works that belong to a single group, and from there proceed to the objects, now a set defined by the catalogue values present in their mutual link (WorkItemRelation) files.
Structure and Rules:
The WorkItemRelationCatalogue entity is linked to the WorkItemRelation entity in a one-to-many relation. One instance of WorkItemRelationCatalogue may be linked to one or many (not zero) instances of WorkItemRelation.
(Unlike records in the WorkItemRelationTypeAuthority and the WorkItemRelationStructure entities, records in WorkItemRelationCatalogue must be linked to WorkItemRelation records.)
Instances of the WorkItemRelation entity may be linked to an instance of WorkItemRelationCatalogue.
Usage:
No recommendation is being made here to govern the syntax of values defined for WorkItemRelationCatalogue. This should be determined by cataloguers and editors.
Fields:
WorkItemRelationCatalogueID
The WorkItemRelationCatalogueID field is the primary key field in the entity. Its values are assigned serially and values from deleted records are retired. This field manifests as a foreign key in the WorkItemRelation entity.
WorkItemRelationCatalogueEntry
This text field is used to enter the name or title of the subject that defines the relationship. It is not clear at this point whether the term should defined so that it follow rules that make it easy to find in a search of the WorkItemRelationCatalogue entity or whether they should use discipline-clear but short references. Most likely when a group term exists (in the catalogue) it will be discovered by searching one of the member objects.
Each term in this field must be unique. Subgroups may be defined such as "Chartres: Interior" or "Chartres: Facade," but subgroups must be treated as unique groups. One way to link high-level groups and sub-groups is to create parallel WorkItemRelation records, one in a low level of a high group and one in a high level of a subgroup. For instance, if there was a group for "Chartres: Exterior" one member of the group may be the South Porch. There would be a link catalogued as "Chartres: Exterior" that connects a general description of the South Elevation with one of the South Porch. The description of the South Porch might then be linked to a description of one of the sculptural groups on the South Porch and this link might then be catalogued as "Chartres: South Porch." This way, when a researcher who begins a hierarchical search lands on the description of the South Porch" a search of the relations attached to the South Porch description will lead to the one in which individual parts of the South Porch is described.
The above strategy also helps keep the number of relations identifying descriptions in a single hierarchy rather low.
Note: It is important to remember that descriptions here are not descriptions of images of works of art, but works of art itself. It may be tempting to think in therms of images and details to order one's appreciation of the grouping mechanism, but be aware that images are described elsewhere -- in the Views entity.
WorkItemRelationCatalogueEntryRecordStatus
This field is used to record the administrative level of completeness of the WorkItemRelationCatalogue record. The terms should follow those designed for similar *RecordStatus fields in this database.
WorkItemRelationCatalogueNote
This MEMO field is used to describe and define how the WorkItemRelationCatalogueEntry is used. It is a scope note that provides help for future editors and cataloguers.
WorkItemRelationCatalogueWHOAssigned
This is a field that is automatically filled in with the moniker of the editor signed onto the system who last changed or created the value of the WorkItemRelationCatalogue record.
WorkItemRelationCatalogueWHENAssigned
This date field is automatically filled in with the system date when the value in WorkItemRelationCatalogueWHOAssigned is first created or updated.
-]
Academic Image Cooperative
Data Model Entity Definitions
SortOrder[6.45]
DIAGRAM_NAME[Work Relations]
Entity_Name[WorkItemRelationCitation]
Entity Type
Independent_Entity[ ] or
Dependent_Entity[x] or
Associative_Entity[ ] or
Subset_Entity[ ]
Entity_Description[ --
Without doubt the kinds of assertions that constitue a WorkItemRelations record may often result from critical and scholarly opinion. It is therefore necessary to offer the cataloguer and editor opportunity to document the source of such assertions. A Citation entity will link such assertions to the Bibliography entity.
A word about using citations. Most of the information that will be coded into the files describing works of art will be presented as common knowledge or as indisputable fact (even when it is the result of the individual or accumulated opinions of historians and experts). In these cases it will be almost impossible -- and probably not to be recommended -- to trace such works down to their sources. When identifications and attributions seem peculiar or new or derived from very old volumes, it may be advisable to enter their sources into the bibliography files. Whenever an image is in dispute -- as for instance happens frequently with works by Rembrandt and other old masters, then, too, whenever possible such information should be tracked to its source.
Structure and Rules:
The citation entity WorkItemRelationCitation is linked to two other entities: to WorkItemRelation and to Bibliography.
1.WorkItemRelation is linked to WorkItemRelationCitation in a one-to-many relationship. One record in WorkItemRelation may be attached to zero, one or many records in WorkItemRelationCitation. One record in WorkItemRelationCitation MUST be attached to one record in WorkItemRelation.
2.The Bibliography entity is linked in a one-to-many relation to WorkItemRelationCitation. One record in the Bibliography entity may be linked to zero, one or many records in the WorkItemRelationCitation entity. One record in the WorkItemRelationCitation entity MUST be related to one record in the Bibliography entity.
Fields:
WorkItemRelationCitationID
The WorkItemRelationCitationID field is the primary key field in the entity. Its values are assigned serially and values from deleted records are retired. This field does not manifest as a foreign key in any other enitty.
WorkItemRelationID
This field is the foreign key that links the WorkItemRelationCitation entity to the WorkItemRelation entity. It may be repeated in records in the WorkItemRelationCitation entity and is required to be a valid number that links to WorkItemRelation.
WorkItemID
WorkItemID/1
These are foreign keys that link through the WorkItemRelation entity to records in the WorkItem entity that are linked via the WorkItemRelation entity. These two fields are artifacts of VISIO and were not intended to be used.
WorkItemRelationTypeAuthorityID
WorkItemRelationStructureID
WorkItemRelationCatalogueID
The three fields above are all artifacts of VISIO and have no functional purpose.
BibliographyID
This is a foreign key in the WorkItemRelationCitation entity that establishes a link to the Bibliography field. It may be repeated in records in the WorkItemRelationCitation entity and is required to be a valid number that links to Bibliography through BibliographyID.
WorkItemRelationCitationReference
This is the text field used to identify the specific location within the attached bibliographic record that points to the usage documented in the WorkItemRelation record.
WorkItemRelationCitationAuthor
Most of the citation entities in this database contain a text field for author. The purpose of this field is to provide a location where the name of the individual responsible for making an assertion (here, a relationship, elsewhere, an attribution, etc.) may be named. The bibliographic citation registered in Bibliography may not by authored by the author of the citation.
WorkItemRelationCitationWhoAssigned
This is a field that is automatically filled in with the moniker of the editor signed onto the system who last changed or created the value of the WorkItemRelationCitation record.
WorkItemRelationCitationWhenAssigned
This date field is automatically filled in with the system date when the value in WorkItemRelationCitationWhoAssigned is first created or updated.
WorkItemRelationCitationRecordStatus
This field is used to record the administrative level of completeness of the WorkItemRelationCitation record. The terms should follow those designed for similar *RecordStatus fields in this database.
-]