NOTE: this is not a finished document, but work in progress.
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.
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.]
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.
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.
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.
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.
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.
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 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".
rdfs:subPropertyOf statements from VRA properties
to DC properties.
http://www.vraweb.org/vracore/vracore3Currently 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.
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.
[Todo: Inverse statements]
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.
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:
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.
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).
[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
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