RDF/OWL Representation of VRA

NOTE: this is not a finished document, but work in progress.

Draft 16 January 2005

Editors:
Mark van Assem, Vrije Universiteit Amsterdam

Abstract

This document describes an RDF/OWL representation of the VRA Core Categories for description of works of art and images of these works.

Status of this Document

...

Acknowledgements

The work described in this document was partly supported by the CHIME project, part of the NWO ToKeN programme.

This representation builds on earlier representations developed in the MIA project by [Hollink et al., 2003] and benefitted from discussions with and comments of Jacco van Ossenbruggen, Laura Hollink, Guus Schreiber, Jan Wielemaker and Bob Wielinga and other members of the Multimedian e-Culture Project (N9C). The author thanks Laura Hollink, Jacco van Ossenbruggen and Antoine Isaac for proofreading this document.

Contents


1. Introduction

The Visual Resource Association (VRA) is an organization consisting of over 600 active members, including many American Universities, galleries and art institutes. These often maintain large collections of (annotated) slides, images and other representations of works of art. The VRA has defined the VRA Core Categories [VRA Data Standards Committee, 2002], to describe such collections. The VRA Core is a set of metadata elements

[...] to describe works of visual culture as well as the images that document them.

This document describes a first attempt at defining an RDF/OWL schema for the Core Categories. Requirements on the schema that were taken into account are that it should:

There is tension between these requirements and this documents explains which trade-offs exist and which choices were made and why. It is an explicit goal here to make it possible to use the VRA to integrate repositories of different institutions with each other.

[TODO: be more precise on where the trade-offs are stated in the document and the choices made.]


2. Files

The schema file that this document describes can be found at http://www.w3.org/2001/sw/BestPractices/MM/vracore3.rdfs.

An example extension of this VRA schema using OWL restrictions can be found at http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs.

An example of how to annotate using this example schema (a Work of the painter Monet and two Images of the painting) can be found at http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf.

This document can be found at http://www.w3.org/2001/sw/BestPractices/MM/vra-conversion.html.


3. Relationship Dublin Core and VRA Core

VRA Core is interpreted here to be a specialization of Dublin Core (DC) for describing works of art and images of works of art. Although this relationship may not be precise on all accounts, in most cases the VRA Core elements are indeed specializations of the corresponding DC elements. The specialization is realized by creating RDF properties that are rdfs:subPropertyOf Dublin Core RDF properties.

[Add ref to DC and DC in RDF]

The RDF/OWL version of VRA Core described in this document is aimed to be compatible with the RDF version of DC, although this has not been explored in detail yet. In principle, an object described using VRA Core RDF/OWL should also be processable by infrastructure that can only operate on the DC RDF schema if that the infrastructure is provided with (and processes) the rdfs:subPropertyOf statements in the VRA RDF/OWL schema.


4. The VRA Model

The underlying model of the VRA Core Categories distinguishes between two types of objects. The first is a work of visual art, which can be almost anything visual ranging from a painting or a statue to a book or an opera. The second is an image depicting a work. There can be many different images "documenting" the same work. The model is kept simple in that it does not provide ways to distinghuish between e.g. a concrete book called "Moby Dick", a particular French edition of the book called "Moby Dick" and the abstract literary work "Moby Dick". These would all be called Works. A JPEG file of the cover of a "Moby Dick" book and a GIF file of a page of text of a "Moby Dick" book are both Images. The VRA Core document does not mention how one should deal with images that are seen as works of art themselves (e.g. digital photographs). Physical photographs or slides are also seen as Images when they are "reproductions" of the Work.

[look up relevant reference - IFLA?]

Besides the concept of Work and Image the model also identifies elements to describe them, for example "Title". To be able to give more specific information elements may have qualifiers, such as "Title.Translation".

The following is a list of all VRA Core elements: Record Type, Type, Title, Measurements, Material, Technique, Creator, Date, Location, ID Number, Style/Period, Culture, Subject, Relation, Description, Source, Rights. See also Appendix A. There is no element to link a Work to its corresponding Image(s), this is considered a "local implementation issue".

The following is an exact copy of the documentation of the "Title" element:

TITLE Qualifiers: Title.Variant Title.Translation Title.Series Title.Larger Entity Definition: The title or identifying phrase given to a Work or an Image. For complex works or series the title may refer to a discrete unit within the larger entity (a print from a series, a panel from a fresco cycle, a building within a temple complex) or may identify only the larger entity itself. A record for a part of a larger unit should include both the title for the part and the title for the larger entity. For an Image record this category describes the specific view of the depicted Work. Data Values: formulated according to data content rules for titles of works of art VRA Core 2.0: W2 Title; V7 Visual Document View Description CDWA: Titles or Names-Text; Related Visual Documentation-View; Related Visual Documentation-View- Indexing Terms Dublin Core: TITLE

Each element is described with its name, its qualifiers, definition, data values (recommendations on data values or vocabularies to use to fill the element), corresponding VRA Core 2.0 elements, corresponding CDWA elements and corresponging Dublin Core elements.

One special metadata element is the RecordType, which should have either the value "work" or "image", and is designed to indicate if a metadata record describes either a work or an image.

The model draws inspiration from Dublin Core and its "dumb down" principle. It defines a mapping to the DC elements that is interpreted here as a specialization relationship. The VRA Core Categories on purpose do not have any associated data format:

VRA Core 3.0 refrains from recommending any type of data structure. Instead, it is hoped that the core elements will help to determine the types of data recorded in a visual resources database and that the concepts can be used to map between databases.

Each element may be repeated as many times as required to describe the work or image, and each element may be applied to both works and images.


5. Translation to RDF/OWL

General approach

Each metadata element is translated into an RDF property, similar to how Dublin Core is represented in RDF. Dublin Core remains neutral on the type of objects on which metadata is stated, but in the case of VRA a distinction is made between works of art and images of works of art.

For almost all VRA properties no rdfs:range is defined in this RDF/OWL schema. The reason is that defining the range to be a certain class or datatype may not be appropriate for all VRA users. To not limit the usefulness of the schema only some ranges were defined and mechanisms to extend VRA Core to local use were explored (see Extending the VRA RDF/OWL schema.

Because no ranges can be stated for most properties, the schema is in OWL Full (OWL DL requires that each property is either an owl:ObjectProperty or an owl:DatatypeProperty). This requirement of OWL DL seems to be in conflict with the "least commitment" guideline of ontology engineering.

The VRA Core schema is both an RDF schema as well as an OWL schema. Statements that define classes and properties are accessible to both RDF and OWL infrastructure under the same set of URIs. The OWL schema provides more information than the RDF schema, but the two versions do not conflict with each other. Whether or not the additional information is processable depends on whether or not one is using OWL-enabled infrastructure or only RDFS-enabled infrastructure. The OWL version does allow for additional inferencing that may result in slightly different behaviour of OWL-enabled infrastructure versus RDFS-enabled infrastructure, see Interoperability of RDF and OWL schemas.

Classes

Three classes are introduced in this schema. The class vra:Work and the class vra:Image are to represent their counterparts in the conceptual model.

A class vra:VisualResource is introduced to group works and images into one class. The classes vra:Work and vra:Image are its subclasses. Although from the point of view of ontology engineering it might not be appropriate to define VisualResource as superclass of the abstract entity Work and the more concrete Image, there is a pragmatic reason: it allows definition of the domain of all properties without resorting to owl:unionOf. See also Interoperability of RDF and OWL schemas.

The classes Work and Image are not defined to be owl:disjointFrom each other, because some Images might be Works of art themselves. How to handle such Images is unclear now, so the current schema does not commit to a particular choice in this case.

Properties

For each element of the Core Categories one property was introduced in the schema, and for each qualifier a subproperty. See Appendix A.

The only exception is the "RecordType" element, for which no corresponding property was created. The function of the RecordType element is to indicate if a VRA "record" is a work or an image. When using the RDF/OWL schema, the rdf:type property should be used to link an individual to the vra:Work or vra:Image class. Here we divert from the requirement of being complete, because we take into account that this is the more usual way in RDF/OWL to represent membership of a "record" to a particular group. In this case it seems reasonable to use the built-in vocabulary instead of introducing a custom property for it.

When introducing properties for VRA there are three issues. First of all, the VRA Core Categories give recommended values for each element. For example, it recommends the ULAN for the creator element, so it might seem appropriate to use the class ulan:Artist as the range for the corresponding creator property (assuming there is a standard RDF version of ULAN). However, three different requirements argue against such a choice: the requirements of extensibility, enabling integration and minimal commitment. For example, it would limit integration possibilities to those repositories that use an RDF version of ULAN (another repository may use string values to represent artists, or instances of a wholly different RDF class). Also, some of the recommendations are for resources that currently do not have an RDF/OWL representation (e.g. LCSH).

[Insert ULAN ref]

A second issue is related to interoperability of RDF and OWL schemas, see Interoperability of RDF and OWL schemas.

A third issue is which properties to define as owl:ObjectProperty and which to define as owl:DatatypeProperty. This issue is related to the first issue, in that choosing either a specific vocabulary such as ULAN or choosing a datatypes such as string or date already determines the choice for owl:ObjectProperty or owl:DatatypeProperty, respectively. Because of this no choice is made in the general schema, except for the following properties:

These two should always have datatypes as ranges. We preclude the possibility to have complex objects as descriptions. These are more appropriately stored in the vra:subject property.

There are a few interrelated decisions regarding the translation of the "relation" element, which according to the documentation should only be used between Works. The decisions are (a) how to represent the link between works and images, and (b) where to position properties between Works and/or Images that are defined in extensions to VRA. An example extension is a property detail, which can be used to indicate that one image is a detail of another image.

The solution that has been chosen here is to define a generic property vra:relation for all relations between works and images (its domain and range is vra:VisualResource instead of vra:Work). We introduce a vra:relation.depicts property with domain vra:Image and range vra:Work to represent the link between works and images. The vra:relation.depicts is a suproperty of the generic vra:relation, and extensions such as ex:detail are defined as a subproperty of vra:relation (see also the example extension in http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs.

There are other possibities besides the one described above, such as using the foaf:depicts property to relate Works to Images. Also, it is possible to stay closer to the original intention of the VRA Core document by defining the domain and range of vra:relation as vra:Work. The reason not to use e.g. foaf:depicts is that the foaf vocabulary may not be stable and it would also mean that vra:Images to which depicts is applied are also foaf:Documents. The reason to set the range of vra:relation to VisualResource is that this provides a common superproperty for all extensions (e.g. ex:detail), which allows "dumbing down" extensions.

The VRA Core document provides examples of annotations in which new qualifiers are introduced that are not part of the actual specification, such as "Relation.PartOf". Such elements may be defined in extensions as subproperties of vra:relation.

See also Adding extension properties.

OWL Property Characteristics

OWL provides the following constructs to define property characteristics:

[add OWL ref]

There is one candidate to declare as transitive: the "relation" property. However, as the semantics of the "relation" element are reasonably vague, we do not think it is appropriate to define it to be a transitive property. Properties that extend "relation" can be declared transitive if this conforms to their semantics.

"Relation" seems the only candidate for symmetry. It also seems unappropriate to declare "relation" to be symmetric. The property can designate all kinds of relations. If someone uses the property to indicate a certain relationship in absence of a more specific property, it should not be assumed that it is a symmetric relationship. Properties that extend "relation" can be declared symmetric if this conforms to their semantics.

No VRA property can be functional, as the VRA Core Categories document specifically states that all elements may be repeated as many times as necessary to describe a Work or Image.

Inverses can be stated for all non-symmetrical properties.

[TODO: define inverses in schema]

The only property that is a likely candidate to define as inverse functional is the "identifier" element. If an identifier uniquely identifies a work of art, also beyond the boundaries of specific institutions, this is an appropriate characteristic. As we cannot guarantee that two institutions have not generated the same identifier to refer to two different objects, we have not given this characteristic to "identifier".

Mappings to other standards

The Core Categories provide mappings to VRA Core 2.0, CDWA and Dublin Core. The schema described in this document only represents the mapping to Dublin Core, as this has an existing RDF representation. Each element is made a subproperty of the DC properties stated in the element description. Although this is not explicitly stated, we feel that most VRA properties are specializations of the DC properties, which warrants the rdfs:subPropertyOf statements from VRA properties to DC properties.

A Base URI for the VRA RDF/OWL schema

A proposal for the base URI for VRA is the following:
  http://www.vraweb.org/vracore/vracore3
Currently there is no vracore3.rdfs file on that location, but it is our intention to contact VRA to request a review of this RDF/OWL version of VRA and also request if the VRA is willing to host an RDF/OWL version of the Core Categories on their servers.

6. Interoperability of RDF and OWL schemas

Interoperability between RDF and OWL here means that information in the same schema should be accessible to OWL-aware infrastructure as well as well as pure RDFS-aware infrastructure as much as possible. This last addition refers to the fact that RDF does not provide the expressivity that OWL does. Therefore, it is impossible for RDF infrastructure to process all constructs that can appear in an OWL schema. In some cases the OWL construct has an appropriate counterpart structure in RDF, in which case it is desirable to ensure that the counterpart is also present in the schema.

For example, RDFS-only infrastructure cannot interpret owl:DatatypeProperty and owl:ObjectProperty statements, although it would be appropriate for them to interpret them as rdf:Property statements. A similar problem exists for owl:Classes. This particular problem can be solved by stating that each OWL property is also an rdf:Property and each OWL class is also an rdfs:Class.

OWL Restrictions

...

Other

[Todo: Inverse statements]


7. Extending the VRA RDF/OWL schema

THe VRA Core schema can be extended by users before it is used in a repository. The word "extending" is used in two senses here: a schema may extend the VRA Core schema by limiting the range of certain VRA Core properties, and a schema may define new properties.

Limiting the range of properties

There are different reasons why one would like to define a range for the VRA Core properties in a local extension:

An extension for providing ranges should be done in such a way as not to hinder the interoperability of different VRA Core repositories (using different extensions). In other words, defining a range for your property should not prohibit you to query other VRA Core data or prevent you from merging repositories defining different ranges. Defining a property to have the range ex:ClassA creates a conflict if another repository states the range to be ex:ClassB. If the two repositories (schemas and objects) are integrated into one (e.g. by putting both in a Sesame RDF server), an RDF tool will conclude that objects in the range of the particular property are of rdf:type ex:ClassA as well as rdf:type ex:ClassB. In OWL, this may even create an inconsistency when the two classes are owl:disjointFrom.

[Ref Sesame]

There are two main approaches which do not hinder interoperability on the general VRA schema level:

In the following examples the existance of a class ulan:Artist is assumed.

[Todo: insert ref to ULAN]

In the first approach, one uses a local namespace to define statements like the following for each property (all in the local namespace, e.g. http://www.example.com/myvra"):

	<rdf:Property rdf:ID="creator">
		<rdfs:range rdf:resource="&ulan;Artist />
		<rdfs:subPropertyOf rdf:resource="&vra;creator>
	</rdf:Property>
	
	<owl:ObjectProperty rdf:about="#creator" />
	
In the second approach, one uses a local namespace to define a new class Work (same procedure for image) with restrictions for each property:
	<rdfs:Class rdf:about="&ex;Work">
	
	    <rdfs:subClassOf rdf:resource="&vra;Work" />
	
	    <rdfs:subClassOf>
		<owl:Restriction>
		    <owl:onProperty rdf:resource="&vra;creator"/>
		    <owl:allValuesFrom rdf:resource="&ulan;Artist"/>
		</owl:Restriction>
	    </rdfs:subClassOf>   

	 </rdfs:Class>


The difference between the two approaches is that in the first a subproperty of the original property is defined with a range (effectively always narrower than the original range, because none was defined). In the second approach the possible values of the original VRA properties are constrained in the context of the local class (we are defining specific subclasses of Work and Images in which the value restrictions hold).

Both approaches enable interoperability between two repositories on the general VRA schema level. A query for Works by a specific vra:creator can be executed on both repositories or on an integrated repository (integrated by e.g. putting both in a Sesame RDF server). A query for all Works with as creator e.g. Rembrant will return works from both repositories provided that the values that are used to represent Rembrandt are the same in both repositories (e.g. both use ulan:Rembrandt) or the different values are mapped to each other (e.g. my:Rembrandt owl:sameAs his:Rembrandt).

The discussion which of these approaches should be recommended practice is beyond the scope of this document. Usage of both approaches does not prohibit the integration of two repositories on the general VRA schema level.

Adding extension properties

Another reason to extend VRA is when the existing properties are not specific enough to represent information that is required by the application at hand. One example is when one wants to represent that one image is a detail of another image. Another is when one wants to represent a common nickname for a work of art. (For example, a famous painting by Dutch painter Rembrandt van Rijn was originally called "Company of Frans Banning Cocq and Willem van Ruytenburch" but is now mostly referred to by its nickname "Night Watch".) Yet another example is to represent common misspellings of titles which may be useful for search purposes.

For such examples, an extension can create a property and define it as a subproperty of one of the generic VRA schema properties. Although the specific semantics of the property is only available to infrastructure which is programmed to process the specific property, the information is then also available to all infrastructure that understands the general VRA Core schema. For example, the local:nickname property can be made a subproperty of vra:title.variant property. This enables infrastructure that is not aware of local:nickname to infer that it is a kind of variant title and display it to a user as such. For this reason, it is recommended that extension properties are defined as subproperty of VRA Core properties, if relevant VRA Core properties are available. The subproperty mechanism may be compared to Dublin Core's "dumb down" mechanism.

Other extension elements that are given as examples in [VRA Data Standards Committee, 2002] are:

In one of the examples the "Relation.Larger entity" seems to be used for the same purpose as "Relation.Part of".

Adding extension classes

Besides images there can be other types of representations of works, such as video. Extensions may introduce subclasses of vra:VisualResource for additional types. Beside the type itself (my:Video) a property should be introduced to link the new type to vra:Work, e.g. my:depicts with domain my:Video and range vra:Work. It is also possible to introduce new relations between representations of Works, e.g. between Images and Videos (such as that a particular Image is a still of a particular Video).

Other repositories that are not aware of the video extension will not know how to process my:Video individuals, although they are able to find them if they search for VisualResources.


8. How to use VRA RDF/OWL

We recommend the following steps for usage of the VRA schema:
  1. If an RDF schema for metadata is already in place, consider either moving all data into the VRA schema or attaching the existing schema to VRA using rdfs:subPropertyOf. If the data does not distinguish between Works and Images, this distinction needs to be made;
  2. Extend the general VRA schema as described in Extending the VRA RDF/OWL schema. Determine which of the extension approaches (subproperties or OWL restrictions) is suitable for defining ranges for the properties;
  3. Consider moving textual descriptions of e.g. "creators" to object descriptions, e.g. using an RDF/OWL version of ULAN. This simplifies integration of different repositories.
An example of how the VRA schema can be extended can be found at http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs. An example of how to annotate using this example schema (a Work of the painter Monet and two Images of the painting) can be found at http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf.

9. Issues and To Do items

Explain why not used xsd:date to define range of "Date"; refer to SWBP WG note on representing time

Describe possibilities for assigning URIs to Works and Images. For Images probably best to use the actual image as URI. For Works discussion exist. Should URI point at actual RDF document or not? Should the thing-described-by.org solution be used?

Did not compare with other VRA conversions, e.g. VRA by Simile.

Some elements do not seem appropriate in the RDF/OWL world, such as the "Title.LargerEntity", which should be used to indicate the name of a larger work of which this work is part of. Rather, it seems better to refer directly to this larger work of art using a relationship between works. This would prevent e.g. editing mistakes when the title is changed in the larger work, but not in its parts.

It seems different extensions for different kinds of part-of should be positioned under vra:relation. Maybe refer to kinds of part-of paper and SWBP WG note on part of.

The vra:type does not seem to be an rdfs:subPropertyOf dc:type, because the latter seems a property intended to be used to describe an aspect of the DC properties themselves. The vra:type seems to be intended to describe the content of a work or image (e.g. that it is a jpeg image).

Should VisualResource actually be the superclass of both Work and Image? Handy for defining the props and keeping it extendable, but probably not entirely correct from Ontology Engineering point of view.

Relationship between VRA qualifiers and DC qualifiers.

Add rdfs:comments and other metadata (e.g. as in the DC schema: dcterms:issues, dcterms:modified, dcterms:hasVersion).

Only defined necessary restrictions on classes, because this minimizes commitment. Is this ok? Only require necessary and sufficient restrictions when one wants to classify instances. Extensions can do this if they want or would that conflict?

Relationship with CIDOC/CRM.

Add inverse properties

Explain naming conventions used

Define appropriate metadata in owl:ontology tag

Possible conflict if local extension requires different kinds of values for images and works. E.g for vra:creator in the context of Works it wants to use ULAN, for Images it wants to use literals.

Define inverse relationships for convenience in querying etc.

Clarify the meaning of elements; for some (e.g. Relation.Identity) this may require contacting VRA itself.

One might also extend VRA by introducing new subclasses, e.g. the class of all works by Rembrandt. Potentially speeds up querying? An OWL class with restrictions can be used to define such a class and if the class is a defined class, this gives an advantage in terms of maintenance (in RDFS explicit typing of individuals that belong to the class is required, for OWL defined classes, this class membership can be inferred).


References

[TODO!]

[Hollink et al., 2003] L.Hollink, A.Th.Schreiber, J.Wielemaker, B.Wielinga. Semantic Annotation of Image Collections. In proceedings of the KCAP'03 Workshop on Knowledge Capture and Semantic Annotation, Florida, October 2003.

[VRA Data Standards Committee, 2002] Visual Resources Association Data Standards Committee, "VRA Core Categories, Version 3.0", 20/2/2002. http://www.vraweb.org/vracore3.htm


Appendix A. List of Core Elements and Qualifiers

The list below is an edited copy of the list in [VRA Data Standards Committee, 2002].

RECORD TYPE
Qualifiers: None
Definition: Identifies the record as being either a WORK record, for the physical or created object, 
	or an IMAGE record, for the visual surrogates of such objects.
Data Values (controlled):  work, image
Dublin Core:  TYPE

TYPE
Qualifiers: None
Definition: Identifies the specific type of Work or Image being described in the record.
Data Values (controlled): recommend AAT
Dublin Core:  TYPE

TITLE
Qualifiers:
    Title.Variant
    Title.Translation
    Title.Series
    Title.Larger Entity
Definition: The title or identifying phrase given to a Work or an Image. For complex works or series 
	the title may refer to a discrete unit within the larger entity (a print from a series, a 
	panel from a fresco cycle, a building within a temple complex) or may identify only the larger 
	entity itself. A record for a part of a larger unit should include both the title for the part 
	and the title for the larger entity. For an Image record this category describes the specific 
	view of the depicted Work.
Data Values: formulated according to data content rules for titles of works of art
Dublin Core:  TITLE

MEASUREMENTS
Qualifiers:
    Measurements.Dimensions
    Measurements.Format
    Measurements.Resolution
Description:  The size, shape, scale, dimensions, format, or storage configuration of the Work or Image. 
	Dimensions may include such measurements as volume, weight, area or running time. The unit used 
	in the measurement must be specified.
Data Values: formulated according to standards for data content (e.g., AACR, etc.)
Dublin Core:  FORMAT

MATERIAL
Qualifiers:
  Material.Medium
  Material.Support
Description: .The substance of which a work or an image is composed.
Data Values (controlled): AAT
Dublin Core:  FORMAT

TECHNIQUE
Qualifiers: None
Description: The production or manufacturing processes, techniques, and methods incorporated in the 
	fabrication or alteration of the work or image.
Data Values (controlled): AAT
Dublin Core:  FORMAT

CREATOR
Qualifiers
    Creator.Role
    Creator.Attribution
    Creator.Personal name
    Creator.Corporate name
Description: The names, appellations, or other identifiers assigned to an individual, group, 
	corporate body, or other entity that has contributed to the design, creation, production, 
	manufacture, or alteration of the work or image.
Data Values (controlled): recommend ULAN and AAAF (LC authority files).
Comment: Controlled list for role (e.g., artist, engraver, architect, etc.) and attribution 
	(e.g., school of, workshop of, circle of, style of, follower of, attributed to, etc.) 
	in development.
Dublin Core: CREATOR, CONTRIBUTOR

DATE
Qualifiers:
    Date.Creation
    Date.Design
    Date.Beginning
    Date.Completion
    Date.Alteration
    Date.Restoration
Description:  Date or range of dates associated with the creation, design, production, 
	presentation, performance, construction, or alteration, etc. of the work or image.  
	Dates may be expressed as free text or numerical.
Data Values:  formulated according to standards for data content (e.g., AACR, DC dates, etc.)
Dublin Core:  DATE, COVERAGE

LOCATION
Qualifiers:
    Location.Current Site
    Location.Former Site
    Location.Creation Site
    Location.Discovery Site
    Location.Current Repository
    Location.Former Repository
Description: The geographic location and/or name of the repository, building, or site-specific 
	work or other entity whose boundaries include the Work or Image.
Data Values (controlled): BHA index, AAAF (LC), Grove's Dictionary of Art Location Appendix
Dublin Core:  CONTRIBUTOR, COVERAGE

ID NUMBER
Qualifiers:
    ID Number.Current Repository
    ID Number.Former Repository
    ID Number.Current Accession
    ID Number.Former Accession
Description:  The unique identifiers assigned to a Work or an Image.
Data Values:
Dublin Core:  IDENTIFIER

STYLE/PERIOD
Qualifiers:
        Style/Period.Style
        Style/Period.Period
        Style/Period.Group
        Style/Period.School
        Style/Period.Dynasty
        Style/Period.Movement
Description:  A defined style, historical period, group, school, dynasty, movement, etc. whose 
	characteristics are represented in the Work or Image.
Data Values (controlled):  recommend AAT
Dublin Core:  COVERAGE, SUBJECT

CULTURE
Qualifiers: None
Description: The name of the culture, people (ethnonym), or adjectival form of a country name 
	from which a Work or Image originates or with which the Work or Image has been associated.
Data Values:  recommend AAT, LCSH
Dublin Core:  COVERAGE

SUBJECT
Qualifiers: None
Description: Terms or phrases that describe, identify, or interpret the Work or Image and what 
	it depicts or expresses.  These may include proper names (e.g., people or events), 
	geographic designations (places), generic terms describing the material world, or topics 
	(e.g., iconography, concepts, themes, or issues).
Data Values: recommend AAT, TGM, ICONCLASS, Sears Subject Headings
Dublin Core: SUBJECT

RELATION
Qualifiers:
        Relation.Identity
        Relation.Type
Description:  Terms or phrases describing the identity of the related work and the relationship 
	between the Work being cataloged and the related work. Note: If the relationship is essential 
	(i.e. when the described work includes the referenced works, either physically or logically 
	within a larger or smaller context), use the Title.Larger Entity element.
Data Values:
Dublin Core: RELATION

DESCRIPTION
Qualifiers: None
Description: A free-text note about the Work or Image, including comments, description, or interpretation, 
	that gives additional information not recorded in other categories.
Data Values:
Dublin Core: DESCRIPTION

SOURCE
Qualifiers: None
Description: A reference to the source of the information recorded about the work or the image.  For a 
	work record, this may be a citation to the authority for the information provided. For an image, 
	it can be used to provide information about the supplying Agency, Vendor or Individual; or,in the 
	case of copy photography, a bibliographic citation or other description of the image source. 
	In both cases, names, locations, and source identification numbers can be included.
Data Values:
Dublin Core:  SOURCE

RIGHTS
Qualifiers: None
Description: Information about rights management; may include copyright and other intellectual property 
	statements required for use.
Data Values:
Dublin Core: RIGHTS