You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1052 lines
42 KiB
1052 lines
42 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
|
|
<!-- $Id: vra-conversion.html,v 1.7 2006/01/16 19:22:53 jvanoss Exp $
|
|
|
|
Document describing an RDF/OWL representation of the VRA element set (Visual Resource Association).
|
|
Defined at http://www.vraweb.org/vracore3.htm
|
|
|
|
Mark van Assem, October 2005.
|
|
|
|
-->
|
|
|
|
<html lang="en">
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1">
|
|
<title>RDF/OWL Representation of VRA</title>
|
|
<style type="text/css">
|
|
body {
|
|
font-family: arial;
|
|
margin-left: +2%;
|
|
margin-right: +2%;
|
|
}
|
|
|
|
emph {
|
|
font-style: italic;
|
|
font-weight: lighter;
|
|
}
|
|
|
|
h1 { font-size: 200%; margin-left: -1%; color: darkblue; margin-top: +2% }
|
|
h2 { font-size: 120%; margin-left: -1%; color: darkblue; margin-top: +2% }
|
|
h3 { font-size: 110%; margin-left: -1%; color: black; margin-top: +2% }
|
|
|
|
hr { margin-left: -1%; }
|
|
|
|
p.ref {
|
|
font-size: 90%}
|
|
p.quote {
|
|
font-style: italic;
|
|
margin-left: +5% ;
|
|
margin-right: +5%
|
|
}
|
|
p.note {
|
|
font-size: 90% ;
|
|
margin-left: +5% ;
|
|
margin-right: +5%}
|
|
p.warning {
|
|
margin-left: +5% ;
|
|
margin-right: +5%;
|
|
font-weight: bold}
|
|
p.caption {
|
|
text-align: center;
|
|
font-weight: bold;}
|
|
p.todo {
|
|
margin-left: +5% ;
|
|
margin-right: +5%;
|
|
font-weight: bold}
|
|
dt {
|
|
font-weight: bold}
|
|
code {
|
|
color: rgb(153, 0, 0);
|
|
font-weight: bold}
|
|
pre {
|
|
color: rgb(153, 0, 0);
|
|
font-size: 90%;
|
|
font-weight: bold;
|
|
margin-left: +2%}
|
|
</style>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<h1>RDF/OWL Representation of VRA</h1>
|
|
|
|
<p><b>NOTE: this is not a finished document, but work in progress.</b></p>
|
|
|
|
<h2>Draft 16 January 2005</h2>
|
|
|
|
|
|
<dl>
|
|
<dt>Editors:</dt>
|
|
<dd><a href="http://www.cs.vu.nl/~mark/">Mark van
|
|
Assem</a>, Vrije Universiteit Amsterdam</dd>
|
|
</dl>
|
|
|
|
|
|
<hr>
|
|
|
|
<!-- end of head -->
|
|
|
|
<h2 class="notoc"><a id="abstract">Abstract</a></h2>
|
|
|
|
This document describes an RDF/OWL representation of the VRA Core Categories for
|
|
description of works of art and images of these works.
|
|
|
|
<h2 id="Status">Status of this Document</h2>
|
|
|
|
...
|
|
|
|
<!-- ACKNOWLEDGEMENTS SECTION -->
|
|
|
|
<h2 id="acknowledgements">Acknowledgements</h2>
|
|
|
|
<p>The work described in this document was partly supported by the
|
|
CHIME project, part of the NWO ToKeN programme.</p>
|
|
|
|
<p>This representation builds on earlier representations developed in the MIA
|
|
project by [<a href="#hollink03">Hollink et al., 2003</a>] 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
|
|
<a href="http://www.multimedian.nl/">
|
|
Multimedian e-Culture Project (N9C)</a>. The author thanks Laura Hollink,
|
|
Jacco van Ossenbruggen and Antoine Isaac for proofreading this document.
|
|
</p>
|
|
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li><a href="#secintroduction">1. Introduction</a></li>
|
|
<li><a href="#secfiles">2. Files</a></li>
|
|
<li><a href="#secdc">3. Relationship Dublin Core and VRA Core </a></li>
|
|
<li><a href="#secvramodel">4. The VRA Model</a></li>
|
|
<li><a href="#sectranslating">5. Translation to RDF/OWL</a></li>
|
|
<li><a href="#secrdfowl">6. Interoperability of RDF and OWL schemas</a></li>
|
|
<li><a href="#secextending">7. Extending the VRA RDF/OWL schema</a></li>
|
|
<li><a href="#sechowtouse">8. How to use VRA RDF/OWL</a></li>
|
|
|
|
<li><a href="#secissues">9. Issues and To Do items</a></li>
|
|
<li><a href="#secreferences">References</a></li>
|
|
<li><a href="#appA">Appendix A. List of Core Elements and Qualifiers</a></li>
|
|
|
|
</ul>
|
|
|
|
<hr/>
|
|
|
|
<!-- INTRODUCTION SECTION -->
|
|
|
|
<h2 id="secintroduction">1. Introduction</h2>
|
|
|
|
<p>The <a href="http://www.vraweb.org">Visual Resource Association</a> (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 [<a name="vracore3">VRA Data Standards Committee, 2002</a>],
|
|
to describe such collections. The VRA Core is a set of metadata elements
|
|
|
|
<p class="quote">[...] to describe works of visual culture as well as the images that document them.
|
|
</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>be as complete as possible;</li>
|
|
<li>provide as much semantics as possible;</li>
|
|
<li>be extensible;</li>
|
|
<li>not make overcommitments;</li>
|
|
<li>enable integration of different repositories;</li>
|
|
<li>be accessible to OWL-aware infrastructure as well as
|
|
well as pure RDFS-aware infrastructure.
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p class="todo">[TODO: be more precise on where the trade-offs are stated in the document and the choices made.]</p>
|
|
|
|
|
|
<!-- SECTION -->
|
|
<hr />
|
|
<h2 id="secfiles">2. Files</h2>
|
|
|
|
<p>The schema file that this document describes can be found at
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/vracore3.owl">http://www.w3.org/2001/sw/BestPractices/MM/vracore3.rdfs</a>.
|
|
</p>
|
|
|
|
<p>An example extension of this VRA schema using OWL restrictions can be found at
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs">http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs</a>.
|
|
</p>
|
|
|
|
<p>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
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf">http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf</a>.
|
|
</p>
|
|
|
|
<p>This document can be found at
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/vra-conversion.html">http://www.w3.org/2001/sw/BestPractices/MM/vra-conversion.html</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="secdc">3. Relationship Dublin Core and VRA Core</h2>
|
|
|
|
<p>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 <code>rdfs:subPropertyOf</code> Dublin Core RDF properties.</p>
|
|
|
|
<p class="todo">[Add ref to DC and DC in RDF]</p>
|
|
|
|
<p>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 <code>rdfs:subPropertyOf</code> statements
|
|
in the VRA RDF/OWL schema.</p>
|
|
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="secvramodel">4. The VRA Model</h2>
|
|
|
|
<p>The underlying model of the VRA Core Categories distinguishes between two types of
|
|
objects. The first is a <em>work of visual art</em>, which can be almost anything
|
|
visual ranging from a painting or a statue to a book or an opera. The second is an <em>image
|
|
depicting a work</em>. 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 <em>"Moby Dick"</em>, a particular French edition of the book
|
|
called <em>"Moby Dick"</em> and the abstract literary work <em>"Moby Dick"</em>. 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.</p>
|
|
|
|
<p class="todo">[look up relevant reference - IFLA?]</p>
|
|
|
|
<p>Besides the concept of <em>Work</em> and <em>Image</em> the model also
|
|
identifies <em>elements</em> to describe them, for example "Title". To be able
|
|
to give more specific information elements may have <em>qualifiers</em>,
|
|
such as "Title.Translation".</p>
|
|
|
|
<p>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 <a href="#appA">Appendix A</a>. There is no element to link a Work to
|
|
its corresponding Image(s), this is considered a "local implementation issue".
|
|
</p>
|
|
|
|
|
|
|
|
<p>The following is an exact copy of the documentation of the "Title" element:<p
|
|
|
|
<pre>
|
|
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</pre>
|
|
|
|
<p>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
|
|
<a href="http://www.getty.edu/research/conducting_research/standards/cdwa/index.html">CDWA</a>
|
|
elements and corresponging Dublin Core elements.</p>
|
|
|
|
<p>One special metadata element is the <code>RecordType</code>, 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.
|
|
|
|
<p>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:</p>
|
|
|
|
<p class="quote">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.</p>
|
|
|
|
<p>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.
|
|
|
|
|
|
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="sectranslating">5. Translation to RDF/OWL</h2>
|
|
|
|
<h3 id="generalapproach">General approach</h3>
|
|
|
|
<p>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 <em>works of art</em> and
|
|
<em>images of works of art</em>.
|
|
</p>
|
|
|
|
<p>For almost all VRA properties no <code>rdfs:range</code> 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 <a href="#secextending">Extending the VRA RDF/OWL schema</a>.
|
|
</p>
|
|
|
|
<p>Because no ranges can be stated for most properties, the schema is in OWL
|
|
Full (OWL DL requires that each property is either an <code>owl:ObjectProperty</code>
|
|
or an <code>owl:DatatypeProperty</code>). This requirement of OWL DL seems to be in
|
|
conflict with the "least commitment" guideline of ontology engineering.
|
|
</p>
|
|
|
|
|
|
<p>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
|
|
<a href="#secrdfowl">Interoperability of RDF and OWL schemas</a>.</p>
|
|
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
|
|
|
|
<h3 id="secclasses">Classes</h3>
|
|
|
|
<p>
|
|
Three classes are introduced in this schema. The class <code>vra:Work</code>
|
|
and the class <code>vra:Image</code> are to represent their counterparts in
|
|
the conceptual model.
|
|
</p>
|
|
|
|
|
|
<p>A class <code>vra:VisualResource</code> is introduced to group works and images
|
|
into one class. The classes <code>vra:Work</code> and <code>vra:Image</code> 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 <code>owl:unionOf</code>. See also
|
|
<a href="#secrdfowl">Interoperability of RDF and OWL schemas</a>.
|
|
</p>
|
|
|
|
<p>The classes Work and Image are not defined to be <code>owl:disjointFrom</code>
|
|
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.
|
|
</p>
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
|
|
|
|
<h3 id="secproperties">Properties</h3>
|
|
|
|
<p>For each element of the Core Categories one property was introduced in the schema,
|
|
and for each qualifier a subproperty. See <a href="#appA">Appendix A.</a></p>
|
|
|
|
<p>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 <code>rdf:type</code> property should be used to link an individual to
|
|
the <code>vra:Work</code> or <code>vra:Image</code>
|
|
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.
|
|
</p>
|
|
|
|
<p>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 <code>creator</code> element, so
|
|
it might seem appropriate to use the class <code>ulan:Artist</code> 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).
|
|
</p>
|
|
|
|
<p class="todo">[Insert ULAN ref]</p>
|
|
|
|
|
|
<p>A second issue is related to interoperability of RDF and OWL schemas, see
|
|
<a href="#secrdfowl">Interoperability of RDF and OWL schemas</a>.</p>
|
|
|
|
<p>A third issue is which properties to define as <code>owl:ObjectProperty</code>
|
|
and which to define as <code>owl:DatatypeProperty</code>. 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
|
|
<code>owl:ObjectProperty</code> or <code>owl:DatatypeProperty</code>, respectively.
|
|
Because of this no choice is made in the general schema, except for the
|
|
following properties:
|
|
</p>
|
|
<ul>
|
|
<li>vra:idNumber</li>
|
|
<li>vra:description</li>
|
|
</ul>
|
|
|
|
<p>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 <code>vra:subject</code> property.</p>
|
|
|
|
|
|
<p>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 <code>detail</code>, which can be used to indicate that one image
|
|
is a detail of another image.</p>
|
|
|
|
<p>The solution that has been chosen here is to define a generic property
|
|
<code>vra:relation</code> for all relations between works and images (its domain
|
|
and range is <code>vra:VisualResource</code> instead of <code>vra:Work</code>). We introduce
|
|
a <code>vra:relation.depicts</code> property with domain <code>vra:Image</code>
|
|
and range <code>vra:Work</code> to represent the link
|
|
between works and images. The <code>vra:relation.depicts</code> is a suproperty
|
|
of the generic <code>vra:relation</code>, and extensions such as <code>ex:detail</code>
|
|
are defined as a subproperty of <code>vra:relation</code> (see also the example
|
|
extension in
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs">http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs</a>.
|
|
</p>
|
|
|
|
<p>There are other possibities besides the one described above, such as using
|
|
the <code>foaf:depicts</code> 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 <code>vra:relation</code> as <code>vra:Work</code>.
|
|
The reason not to use e.g. <code>foaf:depicts</code> is that the
|
|
foaf vocabulary may not be stable and it would also mean that <code>vra:Image</code>s to which depicts
|
|
is applied are also <code>foaf:Document</code>s. The reason to set the range
|
|
of <code>vra:relation</code> to VisualResource is that this provides a common
|
|
superproperty for all extensions (e.g. <code>ex:detail</code>), which allows
|
|
"dumbing down" extensions.
|
|
</p>
|
|
|
|
<p>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 <code>vra:relation</code>.
|
|
</p>
|
|
|
|
<p>
|
|
See also <a href ="#secadding">Adding extension properties</a>.
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
|
|
<h3 id="secowlproperty">OWL Property Characteristics</h3>
|
|
|
|
<p>OWL provides the following constructs to define property characteristics:</p>
|
|
|
|
<p class="todo">[add OWL ref]</p>
|
|
<ul>
|
|
<li>owl:TransitiveProperty;</li>
|
|
<li>owl:SymmetricProperty;</li>
|
|
<li>owl:FunctionalProperty;</li>
|
|
<li>owl:inverseOf;</li>
|
|
<li>owl:InverseFunctionalProperty.</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>"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.
|
|
</p>
|
|
|
|
<p>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.
|
|
</p>
|
|
|
|
<p>Inverses can be stated for all non-symmetrical properties.</p>
|
|
|
|
<p class="todo">[TODO: define inverses in schema]</p>
|
|
|
|
<p>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".</p>
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
|
|
<h3 id="secmappings">Mappings to other standards</h3>
|
|
|
|
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 <code>rdfs:subPropertyOf</code> statements from VRA properties
|
|
to DC properties.
|
|
|
|
<!-- SUBSECTION -->
|
|
|
|
<h3 id="secbasuri">A Base URI for the VRA RDF/OWL schema</h3>
|
|
|
|
A proposal for the base URI for VRA is the following:
|
|
|
|
<pre> http://www.vraweb.org/vracore/vracore3</pre>
|
|
|
|
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.
|
|
|
|
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="secrdfowl">6. Interoperability of RDF and OWL schemas</h2>
|
|
|
|
<p>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 <em>as much as possible</em>. 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.</p>
|
|
|
|
<p>For example, RDFS-only infrastructure cannot interpret <code>owl:DatatypeProperty</code>
|
|
and <code>owl:ObjectProperty</code> statements, although it would be appropriate
|
|
for them to interpret them as <code>rdf:Property</code> statements. A similar
|
|
problem exists for <code>owl:Class</code>es. This particular problem can be
|
|
solved by stating that each OWL property is also an <code>rdf:Property</code>
|
|
and each OWL class is also an <code>rdfs:Class</code>.
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
<h3 id="secrestrictions">OWL Restrictions</h3>
|
|
|
|
...
|
|
|
|
|
|
<!-- SUBSECTION -->
|
|
<h3 id="secother">Other</h3>
|
|
|
|
<p class="todo">[Todo: Inverse statements]</p>
|
|
|
|
<!-- Extending the VRA RDF/OWL schema SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="secextending">7. Extending the VRA RDF/OWL schema</h2>
|
|
|
|
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.
|
|
|
|
<h3 id="seclimiting">Limiting the range of properties</h3>
|
|
|
|
There are different reasons why one would like to define a range for the VRA Core
|
|
properties in a local extension:
|
|
|
|
<ul>
|
|
<li>to generate a data entry system where one can only select values
|
|
from a specific vocabulary defined in the range;</li>
|
|
<li>to check whether the values in the data conform to the specified ranges;</li>
|
|
<li>to be able to infer the class of an object from a property definition.</li>
|
|
</ul>
|
|
|
|
<p>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 <code>ex:ClassA</code> creates a conflict if another repository states
|
|
the range to be <code>ex:ClassB</code>. 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 <code>rdf:type ex:ClassA</code>
|
|
as well as <code>rdf:type ex:ClassB</code>. In OWL, this may even create an
|
|
inconsistency when the two classes are <code>owl:disjointFrom</code>.
|
|
|
|
<p class="todo">[Ref Sesame]</p>
|
|
|
|
<p>There are two main approaches which do not hinder interoperability on the
|
|
general VRA schema level:</p>
|
|
|
|
<ul>
|
|
<li>create subproperties of the VRA schema properties that define their own ranges;</li>
|
|
<li>create OWL restrictions on a local version of the classes vra:Work and vra:Image.</li>
|
|
</ul>
|
|
|
|
<p>In the following examples the existance of a class <code>ulan:Artist</code> is
|
|
assumed.</p>
|
|
|
|
<p class="todo">[Todo: insert ref to ULAN]</p>
|
|
|
|
<p>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"):</p>
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
<rdf:Property rdf:ID="creator">
|
|
<rdfs:range rdf:resource="&ulan;Artist />
|
|
<rdfs:subPropertyOf rdf:resource="&vra;creator>
|
|
</rdf:Property>
|
|
|
|
<owl:ObjectProperty rdf:about="#creator" />
|
|
|
|
</pre>
|
|
|
|
|
|
In the second approach, one uses a local namespace to define a new class Work (same
|
|
procedure for image) with restrictions for each property:
|
|
|
|
<pre>
|
|
<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>
|
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
<p>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).</p>
|
|
|
|
<p>Both approaches enable interoperability between two repositories on the
|
|
general VRA schema level. A query for Works by a specific <code>vra:creator</code>
|
|
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 <code>ulan:Rembrandt</code>) or the
|
|
different values are mapped to each other (e.g. <code>my:Rembrandt owl:sameAs
|
|
his:Rembrandt</code>).
|
|
</p>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
<h3 id="secadding">Adding extension properties</h3>
|
|
|
|
<p>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 <code>detail</code> of another
|
|
image. Another is when one wants to represent a common <code>nickname</code> 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.</p>
|
|
|
|
<p>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 <code>local:nickname</code> property
|
|
can be made a subproperty of <code>vra:title.variant</code> property. This enables
|
|
infrastructure that is not aware of <code>local:nickname</code> 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.</p>
|
|
|
|
<p>Other extension elements that are given as examples in [<a name="vracore3">VRA Data Standards Committee, 2002</a>]
|
|
are:</p>
|
|
|
|
<ul>
|
|
<li>"Relation.Part of" to represent that a work is part of a larger work;</li>
|
|
<li>"Relation.Derived from" to represent that one work was derived from another work (either its design or its actual
|
|
physical components - this is unclear);</li>
|
|
<li>"Relation.Source for" to represent that one work's physical components formed the source for another work.</li>
|
|
</ul>
|
|
|
|
In one of the examples the "Relation.Larger entity" seems to be used for the same purpose as
|
|
"Relation.Part of".
|
|
|
|
|
|
<h3 id="secextensionclasses">Adding extension classes</h3>
|
|
|
|
<p>Besides images there can be other types of representations of works, such as video.
|
|
Extensions may introduce subclasses of <code>vra:VisualResource</code> for additional types.
|
|
Beside the type itself (<code>my:Video</code>) a property should be introduced to
|
|
link the new type to <code>vra:Work</code>, e.g. <code>my:depicts</code> with domain
|
|
<code>my:Video</code> and range <code>vra:Work</code>. 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).
|
|
</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="sechowtouse">8. How to use VRA RDF/OWL</h2>
|
|
|
|
We recommend the following steps for usage of the VRA schema:
|
|
|
|
<ol>
|
|
<li>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;</li>
|
|
<li>Extend the general VRA schema as described in <a href="#secextending">Extending the VRA RDF/OWL schema</a>.
|
|
Determine which of the extension approaches (subproperties or OWL restrictions) is suitable for defining
|
|
ranges for the properties;</li>
|
|
<li>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.</li>
|
|
</ol>
|
|
|
|
An example of how the VRA schema can be extended can be found at
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs">http://www.w3.org/2001/sw/BestPractices/MM/vracore3example.rdfs</a>.
|
|
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
|
|
<a href="http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf">http://www.w3.org/2001/sw/BestPractices/MM/images/examples/eculture-use-case.rdf</a>.
|
|
|
|
|
|
|
|
<!-- SECTION -->
|
|
|
|
<hr />
|
|
<h2 id="secissues">9. Issues and To Do items</h2>
|
|
|
|
|
|
<p>Explain why not used xsd:date to define range of "Date"; refer to SWBP WG note on representing time</p>
|
|
|
|
<p>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?</p>
|
|
|
|
<p>Did not compare with other VRA conversions, e.g. <a href="http://web.mit.edu/simile/2003/10/vraCore3">VRA by Simile</a>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>It seems different extensions for different kinds of part-of should be
|
|
positioned under <code>vra:relation</code>. Maybe refer to kinds of part-of paper
|
|
and SWBP WG note on part of.</p>
|
|
|
|
<p>The <code>vra:type</code> does not seem to be an <code>rdfs:subPropertyOf dc:type</code>, because the latter
|
|
seems a property intended to be used to describe an aspect of the DC properties
|
|
themselves. The <code>vra:type</code> seems to be intended to describe the
|
|
content of a work or image (e.g. that it is a jpeg image).</p>
|
|
|
|
<p>Should <code>VisualResource</code> 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.</p>
|
|
|
|
<p>Relationship between VRA qualifiers and DC qualifiers.</p>
|
|
|
|
<p>Add <code>rdfs:comments</code> and other metadata (e.g. as in the DC schema:
|
|
<code>dcterms:issues</code>, <code>dcterms:modified</code>, <code>dcterms:hasVersion</code>).
|
|
|
|
|
|
<p>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?</p>
|
|
|
|
<p>Relationship with CIDOC/CRM.</p>
|
|
|
|
<p>Add inverse properties</p>
|
|
|
|
<p>Explain naming conventions used</p>
|
|
|
|
<p>Define appropriate metadata in owl:ontology tag</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Define inverse relationships for convenience in querying etc.</p>
|
|
|
|
<p>Clarify the meaning of elements; for some (e.g. Relation.Identity) this
|
|
may require contacting VRA itself.</p>
|
|
|
|
<p>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).</p>
|
|
|
|
|
|
<!-- REFERENCES -->
|
|
|
|
<hr />
|
|
<h2 id="secreferences">References</h2>
|
|
|
|
<p class="todo">[TODO!]</p>
|
|
|
|
<p class="ref">
|
|
[<a name="hollink03">Hollink et al., 2003</a>]
|
|
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.
|
|
</p>
|
|
|
|
<p class="ref">
|
|
[<a name="vracore3">VRA Data Standards Committee, 2002</a>]
|
|
Visual Resources Association Data Standards Committee, "VRA Core Categories, Version 3.0", 20/2/2002.
|
|
<a href="">http://www.vraweb.org/vracore3.htm</a>
|
|
</p>
|
|
|
|
|
|
|
|
<!-- List of elements APPENDIX -->
|
|
|
|
<hr />
|
|
<h2 id="appA">Appendix A. List of Core Elements and Qualifiers</h2>
|
|
|
|
<p>The list below is an edited copy of the list in [<a name="#vracore3">VRA Data Standards Committee, 2002</a>].
|
|
|
|
<pre>
|
|
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
|
|
</pre>
|
|
|
|
</body>
|
|
</html>
|