vra-conversion.html
41.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
<!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>