vra-conversion.html 41.9 KB

Raw Blame History Permalink

<!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>
	&lt;rdf:Property rdf:ID="creator"&gt;
		&lt;rdfs:range rdf:resource="&amp;ulan;Artist /&gt;
		&lt;rdfs:subPropertyOf rdf:resource="&amp;vra;creator&gt;
	&lt;/rdf:Property&gt;

	&lt;owl:ObjectProperty rdf:about="#creator" /&gt;

</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>
	&lt;rdfs:Class rdf:about="&amp;ex;Work"&gt;

	    &lt;rdfs:subClassOf rdf:resource="&amp;vra;Work" /&gt;

	    &lt;rdfs:subClassOf&gt;
		&lt;owl:Restriction&gt;
		    &lt;owl:onProperty rdf:resource="&amp;vra;creator"/&gt;
		    &lt;owl:allValuesFrom rdf:resource="&amp;ulan;Artist"/&gt;
		&lt;/owl:Restriction&gt;
	    &lt;/rdfs:subClassOf&gt;

	 &lt;/rdfs:Class&gt;


</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>