ViewVC logotype

Contents of /trunk/projects/vocabularies/doc/vocabularies.xml

Parent Directory Parent Directory | Revision Log Revision Log

Revision 672 - (show annotations)
Thu Jul 3 15:35:07 2008 UTC (12 years, 4 months ago) by norman.x.gray
File MIME type: text/xml
File size: 73070 byte(s)
Final wording changes in document
Release WD-1.11

1 <?xml version="1.0" encoding="utf-8"?>
2 <!-- Based on template at
3 http://www.ivoa.net/Documents/templates/ivoa-tmpl.html -->
4 <html xmlns="http://www.w3.org/1999/xhtml"
5 xmlns:dc="http://purl.org/dc/elements/1.1/"
6 xmlns:dcterms="http://purl.org/dc/terms/"
7 xml:lang="en" lang="en">
9 <head>
10 <title>Vocabularies in the Virtual Observatory</title>
11 <link rev="made" href="http://nxg.me.uk/norman/#norman" title="Norman Gray"/>
12 <meta name="author" content="Norman Gray"/>
13 <meta name="DC.subject" content="IVOA, Virtual Observatory, Vocabulary"/>
14 <meta name="rcsdate" content="$Date$"/>
15 <link href="http://www.ivoa.net/misc/ivoa_wd.css" rel="stylesheet" type="text/css"/>
16 <style type="text/css">
17 /* make the ToC a little more compact, and without bullets */
18 div.toc ul { list-style: none; padding-left: 1em; }
19 div.toc li { padding-top: 0ex; padding-bottom: 0ex; }
20 li { padding-top: 1ex; padding-bottom: 1ex; }
21 td { vertical-align: top; }
22 td.rdfxml { background: #ECC; }
23 td.turtle { background: #CEC; }
24 span.userinput { font-weight: bold; }
25 span.url { font-family: monospace; }
26 span.rfc2119 { color: #800; }
27 .todo { background: #ff7; }
28 pre { background: #EEE; padding: 1em; }
29 pre.rdfxml { background: #ECC; padding: 1em; }
30 pre.turtle { background: #CEC; padding: 1em; }
32 /* 'link here' text in section headers */
33 *.hlink a {
34 display: none;
35 }
36 *:hover.hlink a {
37 display: inline;
38 color: #800;
39 }
40 </style>
41 </head>
43 <body>
44 <div class="head">
45 <a href="http://www.ivoa.net/"><img alt="IVOA" src="http://www.ivoa.net/pub/images/IVOA_wb_300.jpg" width="300" height="169"/></a>
47 <h1>Vocabularies in the Virtual Observatory<br/>Version @VERSION@</h1>
49 <!-- for release: uncomment this text... -->
50 <h2>IVOA Working Draft, @RELEASEDATE@</h2>
51 <!-- for editors' drafts, uncomment this text...-->
52 <!--
53 <h2>IVOA Working Draft, @RELEASEDATE@ [Editors' draft]</h2>
54 <p><strong>$Revision$ $Date$</strong></p>
55 -->
57 <dl>
59 <dt>This version</dt>
60 <dd><span class='url'>@DOCURI@.html</span></dd>
62 <dt>Latest version</dt>
63 <dd><span class='url'>http://www.ivoa.net/Documents/latest/Vocabularies.html</span><br/>
64 and <a href='@ISSUESLIST@' >issues list</a></dd>
66 <dt>Previous version</dt>
67 <dd><span class='url'>http://www.ivoa.net/Documents/WD/Semantics/vocabularies-20080320.html</span></dd>
69 <dt>Working Group</dt>
70 <dd><em><a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics">Semantics</a></em></dd>
72 <dt>Editors</dt>
73 <dd>Alasdair J G Gray, University of Glasgow, UK<br/>
74 <a href='http://nxg.me.uk/norman/' >Norman Gray</a>, University of
75 Leicester / University of Glasgow, UK<br/>
76 Frederic V Hessman, University of Göttingen, Germany<br/>
77 Andrea Preite Martinez, INAF, Italy</dd>
79 <dt>Authors</dt>
80 <dd>
81 <span property="dc:creator">Sébastien Derriere</span>,
82 <span property="dc:creator">Alasdair J G Gray</span>,
83 <span property="dc:creator">Norman Gray</span>,
84 <span property="dc:creator">Frederic V Hessman</span>,
85 <span property="dc:creator">Tony Linde</span>,
86 <span property="dc:creator">Andrea Preite Martinez</span>,
87 <span property="dc:creator">Rob Seaman</span> and
88 <span property="dc:creator">Brian Thomas</span>
89 </dd>
90 </dl>
91 <hr/>
92 </div>
94 <div class="section-nonum" id="abstract">
95 <p class="title">Abstract</p>
97 <div class="abstract">
98 <p>As the astronomical information processed within the <em>Virtual Observatory
99 </em> becomes more complex, there is an increasing need for a more
100 formal means of identifying quantities, concepts, and processes not
101 confined to things easily placed in a FITS image, or expressed in a
102 catalogue or a table. We propose that the IVOA adopt a standard
103 format for vocabularies based on the W3C's <em>Resource Description
104 Framework</em> (RDF) and <em>Simple Knowledge Organization System</em>
105 (SKOS). By adopting a standard and simple format, the IVOA will
106 permit different groups to create and maintain their own specialised
107 vocabularies while letting the rest of the astronomical community
108 access, use, and combine them. The use of current, open standards
109 ensures that VO applications will be able to tap into resources of the
110 growing semantic web. Several examples of useful astronomical
111 vocabularies are provided, including work on a common IVOA thesaurus
112 intended to provide a semantic common base for VO applications.</p>
113 </div>
115 </div>
117 <div class="section-nonum" id="status">
118 <p class="title">Status of this document</p>
120 <p>This is an IVOA Working
121 Draft. The first release of this document was
122 <span property="dc:date">2008 March 20</span>.</p>
124 <p>This document is an IVOA Working Draft for review by IVOA members
125 and other interested parties. It is a draft document and may be
126 updated, replaced, or obsoleted by other documents at any time. It is
127 inappropriate to use IVOA Working Drafts as reference materials or to
128 cite them as other than <q>work in progress</q>.</p>
130 <p>A list of current IVOA Recommendations and other technical
131 documents can be found at
132 <span class='url' >http://www.ivoa.net/Documents/</span>.</p>
134 <p>This document includes a normative reference to the W3C SKOS
135 standard <span class='cite'>std:skosref</span>, despite the fact that,
136 at the time this present document was standardised, the SKOS document
137 was still a W3C Working Draft and thus a <q>work in progress</q>. The
138 core part of the SKOS standard which this standard refers to (that is,
139 the concept schemes, documentation and intravocabulary relationship
140 vocabularies) are stable, and are very unlikely to change before
141 Recommendation. When the SKOS document becomes a W3C Recommendation,
142 we will issue a minor update to this present document referring to the
143 finalised SKOS standard, and incorporating any errata which have
144 appeared by then.</p>
146 <h3>Acknowledgments</h3>
148 <p>We would like to thank the members of the IVOA semantic working
149 group for many interesting ideas and fruitful discussions.</p>
150 </div>
152 <h2><a id="contents" name="contents">Table of Contents</a></h2>
153 <?toc?>
155 <hr/>
157 <div class="section" id="introduction">
158 <p class="title">Introduction (informative)</p>
160 <div class="section" id='astrovocab'>
161 <p class="title">Vocabularies in astronomy</p>
163 <p>Astronomical information of relevance to the Virtual Observatory
164 (VO) is not confined to quantities easily expressed in a catalogue or
165 a table.
166 Fairly simple things such as position on the sky, brightness in some
167 units, times measured in some frame, redshifts, classifications or
168 other similar quantities are easily manipulated and stored in VOTables
169 and can currently be identified using IVOA Unified Content Descriptors
170 (UCDs) <span class="cite">std:ucd</span>.
171 However, astrophysical concepts and quantities use a wide variety of
172 names, identifications, classifications and associations, most of
173 which cannot be described or labelled via UCDs.</p>
175 <p>There are a number of basic forms of organised semantic knowledge
176 of potential use to the VO. Informal <q>folksonomies</q> are at one
177 extreme, and are a very lightly coordinated collection of labels
178 chosen by users.
179 A slightly more formal structure is a <q>vocabulary</q>, where the label is drawn from a predefined set of definitions which can include relationships to other labels;
180 vocabularies are primarily associated with searching and browsing
181 tasks.
182 At the other extreme are <q>ontologies</q>, where the domain
183 is formally captured in a set of logical classes, typically related in
184 a subclass hierarchy. More formal definitions are presented later in
185 this document.
186 </p>
188 <p>An astronomical ontology is necessary if we are to have a computer
189 (appear to) <q>understand</q> something of the domain.
190 There has been some progress towards creating an ontology of
191 astronomical object types <span
192 class="cite">std:ivoa-astro-onto</span> to meet this need.
193 However there are distinct use cases for letting human users find
194 resources of interest through search and navigation of the information space.
195 The most appropriate technology to meet these use cases derives from
196 the Information Science community, that of <em>controlled
197 vocabularies, taxonomies and thesauri</em>.
198 In the present document, we do not distinguish between controlled
199 vocabularies, taxonomies and thesauri, and use the term
200 <em>vocabulary</em> to represent all three.
201 </p>
203 <p>One of the best examples of the need for a simple vocabulary within
204 the VO is VOEvent <span class="cite">std:voevent</span>, the VO
205 standard for supporting rapid notification of astronomical events.
206 This standard requires some formalised indication of what a published
207 event is <q>about</q>, in a formalism which can be used straightforwardly
208 by the developer of relevant services. See <span class='xref'
209 >usecases</span> for further discussion.</p>
211 <p>A number of astronomical vocabularies have been created, with a
212 variety of goals and intended uses. Some examples are detailed below. </p>
214 <ul>
216 <li>The <em>Second Reference Dictionary of the Nomenclature of
217 Celestial Objects</em> <span class="cite">lortet94</span>, <span
218 class="cite">lortet94a</span> contains 500 paper pages of astronomical
219 nomenclature</li>
221 <li>For decades professional journals have used a set of reasonably
222 compatible keywords to help classify the content of whole articles.
223 These keywords have been analysed by Preite Martinez &amp; Lesteven
224 <span class="cite">preitemartinez07</span>, who derived a
225 set of common keywords constituting one of the potential bases for a
226 fuller VO vocabulary. The same authors also attempted to derive a set
227 of common concepts by analysing the contents of abstracts in journal
228 articles, which should comprise a list of tokens/concepts more
229 up-to-date than the old list of journal keywords. A similar but less
230 formal attempt was made by Hessman <span class='cite'>hessman05</span>
231 for the VOEvent working group, resulting in a similar list.</li>
233 <li>Astronomical databases generally use simple sets of keywords
234 – sometimes hierarchically organised – to help users make queries.
235 Two examples from very
236 different contexts are the list of object types used in the <a
237 href="http://simbad.u-strasbg.fr">Simbad</a> database and the search
238 keywords used in the educational Hands-On Universe image database
239 portal.</li>
241 <li>The Astronomical Outreach Imagery (AOI) working group has created
242 a simple taxonomy for helping to classify images used for educational
243 or public relations <span class="cite">std:avm</span>. See
244 <span class='xref'>vocab-avm</span>.</li>
246 <!--
247 <li>The Hands-On Universe project (see <span class='url'
248 >http://sunra.lbl.gov/telescope2/index.html</span>) has maintained a
249 public database of images for use by the general public since the
250 1990s. The images are very heterogeneous, since they are gathered from
251 a variety of professional, semi-professional, amateur, and school
252 observatories, so a simple taxonomy is used to facilitate browsing
253 by the users of the database.</li>
254 -->
256 <li>In 1993, Shobbrook and Shobbrook published an Astronomy Thesaurus
257 endorsed by the IAU <span class='cite' >shobbrook93</span>. This
258 collection of nearly 3000 terms, in five languages, is a valuable
259 resource, but has seen little use in recent years. Its very size,
260 which gives it expressive power, is a disadvantage to the extent that
261 it is consequently hard to use. See <span class='xref'>vocab-iau93</span>.</li>
263 <li>The VO's Unified Content Descriptors <span class='cite'
264 >std:ucd</span> (UCD) constitute the main controlled vocabulary of the
265 IVOA and contain some taxonomic information. However, UCD has some
266 features which supports its goals, but which make it difficult to use
267 beyond the present applications of labelling VOTables: firstly, there
268 is no standard means of identifying and processing the contents of the
269 text-based reference document; secondly, the content cannot be openly
270 extended beyond that set by a formal IVOA committee without going
271 through a laborious and time-consuming negotiation process of
272 extending the primary vocabulary itself; and thirdly, the UCD
273 vocabulary is primarily concerned with data types and their
274 processing, and only peripherally with astronomical objects (for
275 example, it defines formal labels for RA, flux, and bandpass, but does
276 not mention the Sun). See <span class='xref'>vocab-ucd1</span>.</li>
278 </ul>
279 </div>
281 <div class='section' id='usecases'>
282 <p class='title'>Use-cases, and the motivation for formalised vocabularies</p>
284 <p>The most immediate high-level motivation for this work is the
285 requirement of the VOEvent standard <span class='cite'
286 >std:voevent</span> for a controlled vocabulary usable in the
287 VOEvent's <code>&lt;Why/&gt;</code> and <code>&lt;What/&gt;</code>
288 elements, which describe what
289 sort of object the VOEvent packet is describing, in some broadly
290 intelligible way. For example a <q>burst</q> might be a gamma-ray burst
291 due to the collapse of a star in a distant galaxy, a solar flare, or
292 the brightening of a stellar or AGN accretion disk, and having an
293 explicit list of vocabulary terms can help guide the event publisher
294 into using a term which will be usefully precise for the event's
295 consumers. A free-text label can help here (which brings us into the
296 domain sometimes referred to as folksonomies), but the astronomical
297 community, with a culture sympathetic to international agreement, can
298 do better.</p>
300 <p>The purpose of this proposal is to establish a set of conventions for
301 the creation, publication, use, and manipulation of
302 astronomical vocabularies within the Virtual Observatory, based upon
303 the W3C's SKOS standard. We include as appendices to this proposal
304 formalised versions of a number of existing vocabularies, encoded as
305 SKOS vocabularies <span class="cite">std:skosref</span>.</p>
307 <p>Specific use-cases include the following.</p>
308 <ul>
309 <li>A user wishes to process all events concerning supernovae, which
310 means that an event concerning a type 1a supernova must be understood to be
311 relevant. [This supports a system working autonomously, filtering
312 incoming information.]</li>
314 <li>A user is searching an archive of VOEvents for microlensing
315 events, and retrieves a large number of them; the search interface may
316 then prompt them to narrow their search using one of a set of terms
317 including, say, binary lens events. [This supports so-called <q>semantic
318 search</q>, providing semantic support to an interface which is in turn
319 supporting a user.]</li>
321 <li>A user wishes to search for resources based on the
322 journal-supported keywords in a paper; they might either initiate this by
323 hand, or have this done on their behalf by a tool which can extract
324 the keywords from a PDF. The keywords are in the A&amp;A vocabulary,
325 and mappings have been defined between this vocabulary and others,
326 which means that the query keywords are translated automatically
327 into those appropriate for a search of an outreach image database
328 (everyone likes pretty pictures), the VO Registry, a set of Simbad
329 object types, and one or more concepts in more formal ontologies. The
330 search interface is then able to support the user browsing up and down
331 the AVM vocabulary, and a specialised Simbad tool is able to take
332 over the search, now it has an appropriate starting place. [This
333 supports interoperability, building on the investments which
334 institutions and users have made in existing vocabularies.]</li>
336 <li>A user receives a VOTable of results from a VO application – for
337 example a catalogue of objects or observations – and wants to search a
338 database of old FITS files for potential matches. Because the UCDs
339 labeling the columns of the tables are expressed in well-documented
340 SKOS, both the official descriptions of the UCDs and their semantic
341 matches to a variety of other plain-text vocabularies (such as the IAU
342 or AVM thesauri) are available to the VO application, providing a basis
343 for massive searches for all kinds of FITS keyword values.</li>
345 </ul>
347 <p>The goal of this standard is to show how vocabularies can be easily
348 expressed in an interoperable and computer-manipulable format, and the
349 sole normative section of this Recommendation (namely section <span
350 class='xref'>publishing</span>) contains requirements and suggestions
351 intended to promote this. Four example vocabularies that have
352 previously been expressed using non-standardized formats – namely the
353 A&amp;A keyword list, the IAU thesaurus and AVM taxonomy, and UCD1 – are
354 included below as illustrations of how simple it is to publish them in
355 SKOS, without losing any of the information of the original source
356 vocabularies.</p>
358 <p>It is not a goal of this standard, as it is not a goal of SKOS, to
359 produce knowledge-engineering artefacts which can support elaborate
360 machine reasoning – such artefacts would be very valuable, but require
361 much more expensive work on ontologies. As the supernova use-case
362 above illustrates, even simple vocabularies can support useful machine
363 reasoning.</p>
365 <p>It is also not a goal of this standard to produce new vocabularies,
366 or substantially alter existing ones; instead, the vocabularies
367 included below in section <span class='xref'>distvocab</span> are directly
368 and mechanically
369 derived from existing vocabularies (the exceptions are the IVOAT
370 vocabulary, which is ultimately intended to be a significant update to
371 the IAU-93 original, and the constellations vocabulary, which is
372 intended to be purely didactic). It therefore follows that the ambiguities,
373 redundancies and incompleteness of the source vocabularies are
374 faithfully represented in the distributed SKOS vocabularies. We hope
375 that this formalisation process will create greater visibility and
376 broader use for the various vocabularies, and that this will guide the
377 maintenance efforts of the curating groups.</p>
379 <p>The reason for both of these limitations is that vocabularies are
380 extremely expensive to produce, maintain and deploy, and we must
381 therefore rely on such vocabularies as have been developed, and
382 attached as metadata to resources, by others. Such vocabularies are
383 less rich or less coherent than we might prefer, but they are widely enough
384 deployed to be useful. We hope that the set of example vocabularies
385 we have provided will build on this deployment, by providing material
386 which is useful out of the box.</p>
388 </div>
390 <div class="section" id='formalising'>
391 <p class="title">Formalising and managing multiple vocabularies</p>
393 <p>We find ourselves in the situation where there are multiple
394 vocabularies in use, describing a broad range of resources of interest
395 to professional and amateur astronomers, and members of the public.
396 These different vocabularies use different terms and different
397 relationships to support the different constituencies they cater for.
398 For example, <q>delta Sct</q> and <q>RR Lyr</q> are terms one would
399 find in a vocabulary aimed at professional astronomers, associated
400 with the notion of <q>variable star</q>; however one would
401 <em>not</em> find such technical terms in a vocabulary intended to
402 support outreach activities.</p>
404 <p>One approach to this problem is to create a single consensus
405 vocabulary, which draws terms from the various existing vocabularies
406 to create a new vocabulary which is able to express anything its users
407 might desire. The problem with this is that such an effort would be
408 very expensive, both in terms of time and effort on the part of those
409 creating it, and to the potential users, who have to learn
410 to navigate around it, recognise the new terms, and who have to be
411 supported in using the new terms correctly (or, more often,
412 incorrectly).</p>
414 <p>The alternative approach to the problem is to evade it, and this is
415 the approach taken in this document. Rather than deprecating the
416 existence of multiple overlapping vocabularies, we embrace it,
417 help interest groups formalise as many of them as are appropriate, and
418 standardise the process of formally declaring the relationships between
419 them. This means that:</p>
420 <ul>
421 <li>The various vocabularies are allowed to evolve separately, on
422 their own timescales, managed either by the IVOA, individual working
423 groups within the IVOA, or by third parties;</li>
425 <li>Specialised vocabularies can be developed and maintained by the
426 community with the most knowledge about a specific topic, ensuring
427 that the vocabulary will have the most appropriate breadth, depth, and
428 precision;</li>
430 <li>Users can choose the vocabulary or combination of vocabularies most
431 appropriate to their situation, either when annotating resources, or
432 when querying them; and</li>
434 <li>We can retain the previous investments made in vocabularies by
435 users and resource owners.</li>
437 </ul>
440 </div>
442 </div>
444 <div class='section' id='skos'>
445 <p class='title'>SKOS-based vocabularies (informative)</p>
447 <p>In this section, we introduce the concepts of SKOS-based
448 vocabularies, and the technology of mapping between them. We describe
449 some additional requirements for IVOA vocabularies in the next
450 section, <span class='xref' >publishing</span>.</p>
452 <div class="section" id='vocab'>
453 <p class="title">Selection of the vocabulary format</p>
455 <p>After extensive online and face-to-face discussions, the authors have
456 brokered a consensus within the IVOA community that
457 formalised vocabularies should be published at least in SKOS (Simple Knowledge
458 Organization System) format, a W3C draft standard application of RDF to the
459 field of knowledge organisation <span
460 class="cite">std:skosref</span>. SKOS draws on long experience
461 within the Library and Information Science communities, to address a
462 well-defined set of problems to do with the indexing and retrieval of
463 information and resources; as such, it is a close match to the problem
464 this document is addressing.</p>
466 <p>ISO 5964 <span class='cite' >std:iso5964</span> defines a number of
467 the relevant terms (ISO 5964:1985=BS 6723:1985; see also <span
468 class='cite' >std:bs8723-1</span> and <span class='cite'
469 >std:z39.19</span>), and some of the (lightweight) theoretical
470 background. The only technical distinction relevant to this document
471 is that between vocabulary and thesaurus: BS-8723-1 defines a
472 controlled vocabulary as a</p>
473 <blockquote>
474 prescribed list of terms or headings each one having an assigned meaning
475 [noting that <q>Controlled vocabularies are designed for use in
476 classifying or indexing documents and for searching them.</q>]
477 </blockquote>
478 <p>and a thesaurus as a</p>
479 <blockquote>
480 Controlled vocabulary in which concepts are represented by preferred
481 terms, formally organised so that paradigmatic relationships between
482 the concepts are made explicit, and the preferred terms are
483 accompanied by lead-in entries for synonyms or quasi-synonyms.
484 <!-- NOTE:
485 The purpose of a thesaurus is to guide both the indexer and the
486 searcher to select the same preferred term or combination of preferred
487 terms to represent a given subject. -->
488 (BS-8723-1, sect. 2.39)
489 </blockquote>
490 <p>with a similar definition in ISO-5964 sect. 3.16. The
491 <q>vocabularies</q> discussed in this document are therefore more
492 properly termed thesauri.</p>
494 <p>The paradigmatic relationships in question are those relating a
495 term to a <q>broader</q>, <q>narrower</q> or more generically
496 <q>related</q> term. These notions have an operational definition:
497 any resource retrieved as a result of a search on a given term will
498 also be retrievable through a search on that term's <q>broader
499 term</q> (<q>narrower</q> is a simple inverse, so that for any pair of
500 terms, if <code>A skos:broader B</code>, then <code>B skos:narrower
501 A</code>; a term may have multiple narrower and broader terms). This
502 is not a subsumption relationship, as there is no implication that the
503 concept referred to by a narrower term is of the same <em>type</em> as
504 a broader term. Further, the <code>skos:broader</code> and
505 <code>skos:narrower</code> relationships are not transitive (that is,
506 declaring that if <code>A skos:broader B</code> and <code>B
507 skos:broader C</code> does not imply that <code>A skos:broader
508 C</code>). However the SKOS standard includes the notions of
509 <code>skos:broaderTransitive</code> and
510 <code>skos:narrowerTransitive</code> relations for the subset of
511 vocabularies and systems which would find these useful.</p>
513 <p>Thus <strong>a vocabulary (SKOS or otherwise) is not an
514 ontology</strong>. It has lighter and looser semantics than an
515 ontology, and is specialised for the restricted case of resource
516 retrieval. Those interested in ontological analyses can easily
517 transfer the vocabulary relationship information from SKOS to a formal
518 ontological format such as OWL <span class='cite' >std:owl</span>.</p>
520 <p>The purpose of a thesaurus is to help users find resources they
521 might be interested in, be they library books, image archives, or VOEvent
522 packets.</p>
524 </div>
526 <div class='section' id='skos-format'>
527 <p class='title'>Content and format of a SKOS vocabulary</p>
529 <p>A published vocabulary in SKOS format consists of a set of
530 <q>concepts</q> – an example concept capturing the
531 vocabulary information about spiral galaxies is provided in the <a
532 href='#figexample' >Figure below</a>, with the RDF shown in both
533 RDF/XML <span class='cite' >std:rdfxml</span> and Turtle notation <span
534 class='cite' >std:turtle</span> (Turtle is similar to the more
535 informal <em>Notation3</em>). The elements of a concept are detailed
536 below.</p>
538 <center>
539 <p><a name='figexample' >Figure: examples of a SKOS vocabulary</a></p>
540 <table>
541 <tr>
542 <th class='rdfxml'>XML Syntax</th>
543 <th width="10"/>
544 <th class='turtle'>Turtle Syntax</th>
545 </tr>
546 <tr><td/></tr>
547 <tr>
548 <td class='rdfxml'>
549 <pre class='rdfxml'>
550 &lt;skos:Concept rdf:about="#spiralGalaxy"&gt;
551 &lt;skos:prefLabel lang="en"&gt;
552 spiral galaxy
553 &lt;/prefLabel&gt;
554 &lt;skos:prefLabel lang="de"&gt;
555 Spiralgalaxie
556 &lt;/prefLabel&gt;
557 &lt;skos:notation&gt;
558 5.1.1
559 &lt;/skos:notation&gt;
560 &lt;skos:altLabel lang="en"&gt;
561 spiral nebula
562 &lt;/skos:altLabel&gt;
563 &lt;skos:hiddenLabel lang="en"&gt;
564 spiral glaxy
565 &lt;/hiddenLabel&gt;
566 &lt;skos:definition lang="en"&gt;
567 A galaxy having a spiral structure.
568 &lt;/skos:definition&gt;
569 &lt;skos:scopeNote lang="en"&gt;
570 Spiral galaxies fall into one of
571 three catagories: Sa, Sc, and Sd.
572 &lt;/skos:scopeNote&gt;
573 &lt;skos:narrower
574 rdf:resource="#barredSpiralGalaxy"/&gt;
575 &lt;skos:broader
576 rdf:resource="#galaxy"/&gt;
577 &lt;skos:related
578 rdf:resource="#spiralArm"/&gt;
579 &lt;/skos:Concept&gt;
580 </pre>
581 </td>
582 <td/>
583 <td class='turtle'>
584 <pre class='turtle'>
585 &lt;#spiralGalaxy&gt; a skos:Concept;
586 skos:prefLabel
587 "spiral galaxy"@en,
588 "Spiralgalaxie"@de;
589 skos:notation "5.1.1";
590 skos:altLabel "spiral nebula"@en;
591 skos:hiddenLabel "spiral glaxy"@en;
592 skos:definition """A galaxy having a
593 spiral structure."""@en;
594 skos:scopeNote """Spiral galaxies fall
595 into one of three categories:
596 Sa, Sc, and Sd"""@en;
597 skos:narrower &lt;#barredSpiralGalaxy&gt;;
598 skos:broader &lt;#galaxy&gt;;
599 skos:related &lt;#spiralArm&gt; .
600 </pre>
601 </td>
602 </tr>
603 </table>
604 </center>
606 <p>A SKOS vocabulary includes the following features.</p>
608 <ul>
610 <li>A single URI representing the concept, mainly for use by computers.
611 <!--
612 <code>&lt;#spiralGalaxy&gt; a skos:Concept</code>.
613 <code>&lt;skos:Concept rdf:about="#spiralGalaxy"&gt;</code>
614 -->
615 </li>
617 <li>A single prefered label in each supported language of the
618 vocabulary, for use by humans.
619 <!--
620 <code>skos:prefLabel "spiral galaxy"@en, "Spiralgalaxie"@de</code>.
621 <code>&lt;skos:prefLabel&gt;spiral galaxy&lt;/skos:prefLabel&gt;</code>
622 -->
623 </li>
625 <li>Optional alternative labels which applications may encounter or in
626 common use, whether simple synonyms or commonly-used aliases such as
627 <q>GRB</q> for "gamma-ray burst", or <q>Spiral nebula</q> for
628 spiral galaxies.
629 <!--
630 <code>skos:altLabel "GRB"@en</code>
631 <code>&lt;skos:altLabel lang="de"&gt;Spiralgalaxie&lt;/skos:altLabel&gt;</code>
632 -->
633 </li>
635 <li>Optional hidden labels which capture terms which are sometimes
636 used for the corresponding concept, but which are deprecated in some
637 sense. This might include common misspellings for
638 either the preferred or alternate labels, for example <q>glaxy</q> for
639 <q>galaxy</q>.
640 </li>
642 <li>An optional <q>notation</q> code (such as <code>5.1.1</code> for
643 spiral galaxies within the AVM), used to uniquely identify a
644 concept within a given scheme.</li>
646 <li>A definition for the concept, where one exists in the original
647 vocabulary, to clarify the meaning of the term.
648 <!--
649 <code>skos:definition "A galaxy having a spiral structure."@en</code>
650 <code>&lt;skos:definition lang="en"&gt;<br/>A galaxy having a spiral structure.<br/>&lt;/skos:definition&gt;</code>
651 -->
652 </li>
654 <li>A scope note to further clarify a definition, or the usage of the
655 concept.
656 <!--
657 <code>skos:scopeNote "Spiral galaxies fall into one of three categories: Sa, Sc, and Sd"@en</code>
658 <code>&lt;skos:scopeNote lang="en"&gt;<br/>Spiral galaxies fall into one of three catagories: Sa, Sc, and Sd.<br/>&lt;/skos:scopeNote&gt;</code>
659 -->
660 </li>
662 <li>Optionally, a concept may be involved in any number of relationships
663 to other concepts. The types of relationships are
664 <ul>
665 <li>Narrower or more specific concepts, for example a link to the concept
666 representing a <q>barred spiral galaxy</q>.
667 <!--
668 <code>skos:narrower &lt;#barredSpiralGalaxy&gt;</code>.
669 <code>&lt;skos:narrower rdf:resource="#barredSpiralGalaxy"&gt;</code>
670 -->
671 </li>
672 <li>Broader or more general concepts, for example a link to the token
673 representing galaxies in general.
674 <!--
675 <code>skos:broader &lt;#galaxy&gt;</code>.
676 <code>&lt;skos:broader rdf:resource="#galaxy"&gt;</code>
677 -->
678 </li>
679 <li>Related concepts, for example a link to the token representing spiral
680 arms of galaxies
681 <!--
682 <code>skos:related &lt;#spiralArm&gt;</code>
683 <code>&lt;skos:related rdf:resource="#spiralArm"&gt;</code>
684 -->
685 <br/>
686 (note this relationship does not say that spiral galaxies have spiral
687 arms – that would be ontological information of a higher order which
688 is beyond the requirements for information stored in a vocabulary).</li>
689 </ul>
690 </li>
691 </ul>
693 <p>In addition to the information about a single concept, a vocabulary
694 can contain information to help users navigate its structure and
695 contents:</p>
696 <ul>
697 <li>The <q>top concepts</q> of the vocabulary, i.e. those that occur
698 at the top of the vocabulary hierarchy defined by the broader/narrower
699 relationships, can be explicitly stated to make it easier to navigate
700 the vocabulary.</li>
702 <li>Concepts that form a natural group can be defined as being members
703 of a <q>collection</q>.</li>
705 <li>Versioning information can be added using change notes.</li>
707 <li>Additional metadata about the vocabulary, for example indicating
708 the publisher, may be documented using the Dublin Core metadata set
709 <span class='cite' >std:dublincore</span>, <span
710 class='cite'>std:pubguide</span>. At a minimum, the vocabulary's
711 <code>skos:ConceptScheme</code> should be annotated with DC title,
712 creator, description and date terms.</li>
714 <li>The SKOS standard describes a number of <q>documentation
715 properties</q>; these should be used to document provenance of and
716 changes to vocabulary terms.</li>
718 <li>A set of mappings between the concepts in different vocabularies
719 see section <span class='xref'>skos-relationships</span></li>
720 </ul>
722 <p>Note, the set of mappings between vocabularies has the potential to be
723 circular or create inconsistencies, though this is probably reasonably
724 unlikely in fact. This is in principle out of the
725 control of the vocabulary authors, since vocabularies do not contain
726 mappings, and so this can only be detected dynamically by applications
727 which use the vocabularies.</p>
729 </div>
732 <div class='section' id='skos-relationships'>
733 <p class='title'>Mapping relationships between vocabularies</p>
735 <p>There already exist several vocabularies in the domain of astronomy.
736 Instead of attempting to replace all these existing vocabularies,
737 which have been developed to achieve different aims and user groups,
738 we embrace them.
739 This requires a mechanism to relate the concepts in the different
740 vocabularies.</p>
742 <p>Part of the SKOS working draft standard <span class='cite'>std:skosref</span>
743 allows a concept in one vocabulary to be related to a concept in
744 another vocabulary.
745 There are four types of relationship provided to capture the
746 relationships between concepts in vocabularies, which are similar to
747 those defined for relationships between concepts within a single
748 vocabulary.
749 The types of mapping relationships are as follows.</p>
751 <ul>
753 <li>
754 Equivalence between concepts, i.e. the concepts in the different
755 vocabularies refer to the same real world entity.
756 This is captured with the RDF statement
757 <blockquote>
758 <code>AAkeys:#Cosmology skos:exactMatch avm:#Cosmology</code>
759 </blockquote>
760 which states that the cosmology concept in the A&amp;A Keywords is the
761 same as the cosmology concept in the AVM.
762 (Note the use of an external namespaces <code>AAkeys</code> and
763 <code>avm</code> which must be defined within the document.)
764 </li>
766 <li>
767 Broader concept, i.e. there is not an equivalent concept but there is
768 a more general one.
769 This is captured with the RDF statement
770 <blockquote>
771 <code>AAkeys:#Moon skos:broadMatch avm:PlanetSatellite</code>
772 </blockquote>
773 which states that the AVM concept <q>Planet Satellite</q> is a more general
774 term than the A&amp;A Keywords concept <q>Moon</q>.
775 </li>
777 <li>
778 Narrower concept, i.e. there is not an equivalent concept but there is
779 a more specific one.
780 This is captured with the RDF statement
781 <blockquote>
782 <code>AAkeys:#IsmClouds skos:narrowMatch
783 avm:#NebulaAppearanceDarkMolecularCloud</code>
784 </blockquote>
785 which states that the AVM concept <q>Nebula Appearance Dark Molecular
786 Cloud</q> is more specific than the A&amp;A Keywords concept <q>ISM Clouds</q>.
787 </li>
789 <li>
790 Related concept, i.e. there is some form of associative relationship.
791 This is captured with the RDF statement
792 <blockquote>
793 <code>AAkeys:#BlackHolePhysics skos:relatedMatch
794 avm:#StarEvolutionaryStageBlackHole</code>
795 </blockquote>
796 which states that the A&amp;A Keywords concept <q>Black Hole Physics</q> has
797 an association with the AVM concept <q>Star Evolutionary Stage Black Hole</q>.
798 </li>
800 </ul>
802 <p>The semantic mapping relationships have certain properties.
803 The broadMatch relationship has the narrowMatch relationship as its
804 inverse and the exactMatch and relatedMatch relationships are
805 symmetrical.
806 The consequence of these properties is that if you have a mapping from
807 concept <code>A</code> in one vocabulary to concept <code>B</code> in
808 another vocabulary then you can infer a mapping from concept
809 <code>B</code> to concept <code>A</code>.
810 </p>
812 <p class='todo'>At the time of writing, the SKOS document is still a
813 working draft, and may or may not end up with support for mappings in
814 the core document rather than in a companion document. This section
815 of this Working Draft, and other references to mappings below, should
816 therefore be considered as current best practice and could be updated
817 in a subsequent version of this document once the SKOS document has
818 become a standard.</p>
820 </div>
822 <div class='section' id='vocabversions'>
823 <p class='title'>Vocabulary versions</p>
825 <p>The document <span class='cite'>kendall08</span> discusses good
826 practice for managing RDF vocabularies. At the time of writing (2008
827 May) this is still an editor's draft, and it itself notes that good
828 practice in this area is not yet fully stable, so our recommendations
829 here are necessarily tentative, and in some places restricted to the
830 relatively small vocabularies (100s to 1000s of terms) we expect to
831 encounter in the VO. We expect to adjust or enhance this advice in
832 future editions of this Recommendation, as best practice evolves, or
833 as we gain more experience with the relevant vocabularies.</p>
835 <p>We must distinguish between versions of a vocabulary, and versions
836 of the description of a vocabulary. In the former case, we are
837 concerned with the presence or absence of certain concepts, such as
838 <q>star</q> or <q>GRB</q>, and expect that there will be some
839 reasonably stable relationship between the concept URI and the
840 real-world concept it refers to. In the latter case, we are concerned
841 with the technicalities of associating a concept URI with its
842 labels, its description, and with other related concept URIs. While
843 it is true that there are epistemological commitments involved in the
844 simple act of naming (and the terms <q>GRB</q> and <q>planet</q>
845 remind us that there is knowledge implicit within a name), it is the
846 latter case that generally represents the <em>knowledge</em> we have
847 of an object, and it is this knowledge which we must version. For
848 example, the concept of <q>planet</q> is a stable one, and so should
849 not be versioned, but the <em>definition</em> of a planet was changed
850 by the IAU in 2006, so that the description of a vocabulary term such
851 as <q>planet</q> would have changed then, and should be versioned.</p>
853 <p>In consequence, <em>the concept URIs should not carry
854 version information</em>. The partial exception to this is when a
855 vocabulary undergoes a major restructuring, as a result of the terms
856 in it becoming significantly incoherent – for example, we might
857 imagine the IAU93 thesaurus being updated to form an IAU 200x
858 thesaurus – but in this case we should regard the result as a new
859 vocabulary, rather than simply an adjusted version of an old one.</p>
861 <p>All the terms in the SKOS vocabulary appear in an unversioned
862 namespace, and once in the vocabulary they are not removed <span
863 class='cite'>kendall08</span>. Successive versions of the vocabulary
864 description describe the vocabulary terms as <q>unstable</q>, <q>testing</q>,
865 <q>stable</q> or <q>deprecated</q>.</p>
866 <!-- there seems to be no
867 discussion of this in a SKOS document, as opposed to commentary on
868 SKOS -->
870 <p>The Dublin Core namespaces are managed in a similar way <span
871 class='cite'>dc:namespaces</span>. The namespace URIs, which act as
872 common prefixes to the DC terms, and which are defined using a <q>hash
873 URI</q> strategy, in RDF terms, have no version numbers, so that
874 the namespace for the DC terms vocabulary is <span
875 class='url'>http://purl.org/dc/terms/</span>. Terms such as <span
876 class='url'>http://purl.org/dc/terms/extent</span> then 302-redirect
877 to a URL which, for administrative convenience, happens to contain a
878 release date, but which resolves to RDF which defines the unversioned
879 term <span class='url'>http://purl.org/dc/terms/extent</span>. This
880 file includes the following content (translated into Turtle from the
881 original RDF/XML for legibility).</p>
882 <pre>@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
883 @prefix skos: &lt;http://www.w3.org/2008/05/skos#&gt; .
884 @prefix dcam: &lt;http://purl.org/dc/dcam/&gt; .
885 @prefix dcterms: &lt;http://purl.org/dc/terms/&gt; .
886 @prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
888 &lt;http://purl.org/dc/terms/&gt;
889 dcterms:title """DCMI Namespace for metadata terms
890 in the http://purl.org/dc/terms/ namespace"""@en-us;
891 rdfs:comment """To comment on this schema,
892 please contact dcmifb@dublincore.org.""";
893 dcterms:publisher "The Dublin Core Metadata Initiative"@en-us;
894 dcterms:modified "2008-01-14" .
896 dcterms:extent
897 rdfs:label "Extent"@en-us;
898 rdfs:comment "The size or duration of the resource."@en-us;
899 rdfs:isDefinedBy &lt;http://purl.org/dc/terms/&gt;;
900 dcterms:issued "2000-07-11";
901 dcterms:modified "2008-01-14";
902 a rdf:Property;
903 dcterms:hasVersion &lt;http://dublincore.org/usage/terms/history/#extent-003&gt;;
904 rdfs:range dcterms:SizeOrDuration;
905 rdfs:subPropertyOf &lt;http://purl.org/dc/elements/1.1/format&gt;,
906 dcterms:format .
907 ...
908 </pre>
909 <p>This includes the definition of the (unversioned) <span class='url'
910 >http://purl.org/dc/terms/extent</span> concept, along with semantic
911 knowledge about the concept (<code>rdfs:subPropertyOf</code>) as of
912 2008-01-14, plus other editorial (<code>dcterms:modified</code>) and
913 definitional (<code>rdfs:isDefinedBy</code>) metadata.</p>
915 </div>
917 </div>
919 <div class='section' id='publishing'>
920 <p class='title'>Publishing vocabularies (normative)</p>
922 <div class='section' id='pubreq'>
923 <p class='title'>Requirements</p>
925 <p>A vocabulary which conforms to this IVOA standard has the following
926 features. In this section, the keywords
927 <span class='rfc2119' >must</span>,
928 <span class='rfc2119' >should</span>
929 and so on, are to be interpreted as described in <span
930 class='cite'>std:rfc2119</span>.</p>
932 <div class='section'>
933 <p class='title'>Dereferenceable namespace</p>
935 <p>The namespace of the vocabulary <span class='rfc2119'>must</span>
936 be dereferenceable on the web. That is, typing the namespace URL into
937 a web browser will produce human-readable documentation about the
938 vocabulary. In addition, the namespace URL <span class='rfc2119'
939 >should</span> return an RDF version of the vocabulary if it is
940 retrieved with one of the RDF MIME types in the HTTP Accept header.
941 At the time of writing, the only fully standardised RDF MIME type is
942 <code>application/rdf+xml</code> for RDF/XML, but
943 <code>text/rdf+n3</code> and <code>text/turtle</code> are the proposed
944 types for Notation3 <span class='cite'>notation3</span> and Turtle
945 <span class='cite'>std:turtle</span>, respectively.</p>
947 <p><em>Rationale: These prescriptions are intended to be compatible
948 with the patterns described in <span class='cite'>berrueta08</span>
949 and <span class='cite'>sauermann08</span>, and vocabulary distributors
950 <span class='rfc2119' >should</span> follow these patterns where
951 possible.</em></p>
952 </div>
954 <div class='section'>
955 <p class='title'>Long-term availability</p>
957 <p>The files defining a vocabulary, including those of superseded
958 versions, <span class='rfc2119' >should</span> remain permanently
959 available. There is no requirement that the namespace URL be at any
960 particular location, although the IVOA web pages, or a journal
961 publisher's web pages, would likely be suitable archival
962 locations.</p> </div>
964 <div class='section'>
965 <p class='title'>Distribution format</p>
967 <p>Vocabularies <span class='rfc2119'>must</span> be made available
968 for distribution as SKOS RDF files in RDF/XML <span
969 class='cite'>std:rdfxml</span> format. A human readable version in
970 Turtle <span class='cite'>std:turtle</span> format <span
971 class='rfc2119'>should</span> also be made available. As an
972 alternative to Turtle, vocabularies may be made available in that
973 subset of Notation3 <span class='cite'>notation3</span> which is
974 compatible with Turtle; if Turtle or Notation3 is being served, it is
975 prudent to support both <code>text/rdf+n3</code> and
976 <code>text/turtle</code> as MIME types in the <code>Accept</code>
977 header of the HTTP request. <!-- See issue <a
978 href='@ISSUESLIST@#distformat-2'>[distformat-2]</a> --></p>
980 <p>A publisher <span class='rfc2119'>may</span> make available RDF in
981 other formats, or other supporting files. A publisher <span
982 class='rfc2119'>must</span> make available at least some
983 human-readable documentation – see section <span
984 class='xref'>servevocab</span> for a discussion of the mechanics here.</p>
986 <p><em>Rationale: this does imply that the vocabulary source files can only
987 realistically be parsed using an RDF parser. An alternative is to
988 require that vocabularies be distributed using a subset of RDF/XML
989 which can also be naively handled as traditional XML; however as well
990 as creating an extra standardisation requirement, this would make it
991 effectively infeasible to write out the distribution version of the
992 vocabulary using an RDF or general SKOS tool.</em></p>
993 </div>
995 <div class='section' id='versioning'>
996 <p class='title'>Clearly versioned vocabulary</p>
998 <p>The vocabulary <em>namespace</em> <span class='rfc2119' >should
999 not</span> be versioned, but it <span class='rfc2119' >should</span>
1000 be easy to retrieve earlier versions of the RDF describing the
1001 vocabulary. See the discussion in section <span
1002 class='xref'>vocabversions</span> for the rationale for this, and see
1003 section <span class='xref'>servevocab</span> for a discussion of its
1004 implications for the way that vocabularies are served on the web.</p>
1006 <!-- Issue <a href='@ISSUESLIST@#versioning-3' >[versioning-3]</a>-->
1008 </div>
1010 <div class='section'>
1011 <p class='title'>No restrictions on source files</p>
1013 <p>This Recommendation does not place any restrictions on the format of the
1014 files managed by the maintenance process, as long as the distributed
1015 files are as specified above.
1016 <!-- See issue
1017 <a href='@ISSUESLIST@#masterformat-1' >[masterformat-1]</a> -->
1018 </p>
1019 </div>
1021 </div>
1023 <div class='section' id='practices'>
1024 <p class='title'>Good practices of vocabulary design</p>
1026 <p>This standard imposes a number of requirements on conformant
1027 vocabularies (see <span class='xref' >pubreq</span>). In
1028 this section we list a number of good practices that IVOA vocabularies
1029 <span class='rfc2119'>should</span> abide by. Some of the
1030 prescriptions below are more specific than good-practice guidelines
1031 for vocabularies in general.</p>
1033 <p>The adoption of the following guidelines will make it easier to use
1034 vocabularies in generic VO applications. However, VO applications
1035 <span class='rfc2119'>must</span> be able to accept any vocabulary
1036 that complies with the latest SKOS standard
1037 <span class="cite">std:skosref</span> (this is a syntactical
1038 requirement, and does not imply that an application will necessarily
1039 understand the terms in
1040 an alien vocabulary, although the presence of mappings to a known
1041 vocabulary should allow it to derive some benefit).</p>
1043 <ol>
1045 <li>SKOS concepts are identified by strings which are, syntactically,
1046 the fragment part of a URI. As such, these identifiers must be
1047 composed of characters from a restricted set. The URI specification
1048 <span class='cite'>std:rfc3986</span> permits a broad range of
1049 characters in a URI fragment, but for simplicity, we recommend here
1050 that concepts be identified by more restricted strings, and <span
1051 class='rfc2119'>should</span> match the regular expression
1052 <code>^[A-Za-z][A-Za-z0-9._-]*$</code>.</li>
1054 <li>For the sake of expert users working directly with the concept
1055 URIs, the concept identifiers <span class='rfc2119'>should</span> be
1056 kept in human-readable form, directly reflecting the concept's
1057 label, or place in a hierarchy, and not be semi-random identifiers
1058 only (for example, use <code>spiralGalaxy</code>, not
1059 <code>t1234567</code>). [Rationale: When working with very large or
1060 complicated vocabularies and ontologies, it is useful to have opaque
1061 concept labels, to avoid confusion arising from the intuitive
1062 semantics of a recognisable label. This is less of a danger with the
1063 simpler vocabularies we are discussing here, so we can safely retain the convenience of recognisable concept identifiers.]</li>
1065 <li>Labels <span class='rfc2119'>should</span> be unchanged from the
1066 labels appearing in the source vocabulary. When developing a
1067 <em>new</em> vocabulary, standard thesaurus practice indicates that
1068 english language labels for concrete concepts should be pluralised,
1069 though abstract concepts remain singular – thus
1070 <code>"galaxies"@en</code>, but <code>"astronomy"@en</code>; thesaurus
1071 practice in other languages uses the singular for all
1072 cases.</li>
1074 <li>Each concept <span class='rfc2119'>should</span> have a definition
1075 (<code>skos:definition</code>) that constitutes a short description of
1076 the concept which could be adopted by an application using the
1077 vocabulary. Each concept <span class='rfc2119'>should</span> have
1078 additional documentation using SKOS Notes or
1079 Dublin Core terms as appropriate
1080 (see <span class='cite'>std:skosref</span>). In practice, this
1081 requirement is rather difficult to satisfy, when converting pre-existing
1082 structured vocabularies to SKOS, since these frequently provide
1083 only labels, without fuller descriptions or scope notes.</li>
1085 <li>The language localisation <span class='rfc2119'>should</span> be
1086 declared where appropriate, in preferred labels, alternate labels,
1087 definitions, and the like. Thus, use <code>"galaxies"@en</code>,
1088 rather than just <code>"galaxies"</code>, even if there is only one
1089 language being used in the vocabulary.</li>
1091 <li>Relationships (<q>broader</q>, <q>narrower</q>, <q>related</q>)
1092 between concepts <span class='rfc2119'>should</span> be present, but
1093 are not required; if used, they <span class='rfc2119'>should</span> be
1094 complete (thus all <q>broader</q> links have corresponding
1095 <q>narrower</q> links in the referenced entries and <q>related</q>
1096 entries link each other).</li>
1098 <li>A vocabulary <span class='rfc2119'>should</span> indicate the <q>top concepts</q> in the vocabulary (namely those concepts that do not have any <q>broader</q> relationships), using the <code>skos:hasTopConcept</code> relation. This should be done only if the vocabulary is structured enough that this is useful.</li>
1100 <li>The SKOS standard describes some good practices for vocabulary
1101 maintenance, such as using <code>&lt;skos:changeNote&gt;</code> and
1102 the like, and these are elaborated in the (currently draft) note <span
1103 class='cite'>kendall08</span>. At a minimum, the vocabulary's
1104 <code>skos:ConceptScheme</code> <span class='rfc2119'>must</span> be
1105 annotated with DC title, creator, and date terms
1106 <span class='cite'>std:dublincore</span>,
1107 <span class='cite'>std:pubguide</span>.
1108 Publishers <span class='rfc2119'>should</span> respect such good practices
1109 as are available to direct vocabulary development and
1110 maintenance.</li>
1112 <li>Publishers <span class='rfc2119'>should</span> publish
1113 <q>mappings</q> between their vocabularies and other commonly used
1114 vocabularies (see <span class='xref'>distmappings</span>). These <span
1115 class='rfc2119'>must</span> be external to
1116 the defining vocabulary document so that the vocabulary can be used
1117 independently of the publisher's mappings. The mapping file <span
1118 class='rfc2119' >must</span> be annotated with DC title, creator, description and date terms <span class='cite'>std:dublincore</span>,
1119 <span class='cite'>std:pubguide</span>.</li>
1121 <li>When adapting an existing vocabulary into the SKOS format,
1122 implementors <span class='rfc2119'>should not</span> change the form
1123 of labels (for example changing the grammatical number) beyond any
1124 changes necessarily required by SKOS.</li>
1126 </ol>
1128 <!--
1129 <p>These suggestions are by no means trivial – there was
1130 considerable discussion within the semantic working group on many of
1131 these topics, particularly about token formats (some wanted lower-case
1132 only), and singular versus plural forms of the labels (different
1133 traditions exist within the international library science
1134 community). Obviously, no publisher of an astronomical vocabulary has
1135 to adopt these rules, but the adoption of these rules will make it
1136 easier to use the vocabularly in external generic VO
1137 applications. However, VO applications should be developed to accept
1138 any vocabulary that complies with the latest SKOS standard <span
1139 class="cite">std:skosref</span>.</p>
1140 -->
1141 </div>
1143 <div class='section' id='servevocab'>
1144 <p class='title'>Good practices when serving vocabularies on the web</p>
1146 <p>The W3C Interest Group Note <em>Cool URIs for the Semantic Web</em>
1147 <span class='cite'>sauermann08</span> presents guidelines for the
1148 effective use of URIs when serving web documents and concepts on the
1149 Semantic Web. When providing vocabularies to the VO, we recommend
1150 that publishers conform to these guidelines in general. We make some
1151 further observations below.</p>
1153 <p>The “Cool URIs” guidelines describe a number of desirable
1154 features of URIs in this context, namely simplicity, stability and
1155 manageability. Section 4.5 of the document describes
1156 these features as follows (quoted directly).</p>
1157 <dl>
1158 <dt>Simplicity</dt>
1159 <dd>Short, mnemonic URIs will not break as easily when sent in emails
1160 and are in general easier to remember, e.g. when debugging your
1161 Semantic Web server.</dd>
1162 <dt>Stability</dt>
1163 <dd>Once you set up a URI to identify a certain resource, it should
1164 remain this way as long as possible. Think about the next ten
1165 years. Maybe twenty. Keep implementation-specific bits and pieces such
1166 as .php and .asp out of your URIs, you may want to change technologies
1167 later.</dd>
1168 <dt>Manageability</dt>
1169 <dd>Issue your URIs in a way that you can manage. One good practice is
1170 to include the current year in the URI path, so that you can change
1171 the URI-schema each year without breaking older URIs. Keeping all 303
1172 URIs on a dedicated subdomain,
1173 e.g. <code>http://id.example.com/alice</code>, eases later migration
1174 of the URI-handling subsystem.</dd>
1175 </dl>
1176 <p>We endorse this advice in this Recommendation: VO vocabularies
1177 <span class='rfc2119'>should</span> use URIs which have these
1178 properties. The advice in the third point is a general point about
1179 maintaining the general URI namespace on a particular server, and is
1180 not about versioning vocabulary namespaces.</p>
1182 <p>The “Cool URIs” document also describes two broad strategies for
1183 making these URIs available on the web, which they name <em>303
1184 URIs</em> and <em>hash URIs</em> (see the document, section 4, for
1185 descriptions). They note that the <em>hash URI</em> strategy <q>should
1186 be preferred for rather small and stable sets of resources that evolve
1187 together. The ideal case[s] are RDF Schema vocabularies and OWL
1188 ontologies, where the terms are often used together, and the number of
1189 terms is unlikely to grow out of control in the future.</q> Since
1190 this is the case for the (relatively small) SKOS vocabularies this
1191 Recommendation discusses, and since an application will generally want
1192 to use the complete vocabulary rather than only single concepts, we
1193 suggest that vocabularies conformant to this Recommendation <span
1194 class='rfc2119'>should</span> be distributed as <em>hash URI</em>
1195 ones.</p>
1197 <p>Common to the two strategies above is the insistence that the
1198 vocabulary URIs <em>are HTTP URIs which are retrievable on the
1199 web</em> – they differ only in the practicalities of achieving this.
1200 The strategies also share the expectation that the vocabulary URIs are
1201 retrievable both as RDF (machine-readable) and as HTML (providing
1202 documentation for humans). We elevate this to a requirement of this
1203 Recommendation: vocabulary terms <span class='rfc2119'>must</span> be
1204 HTTP URIs which <span class='rfc2119'>must</span> be dereferenceable
1205 as both RDF and HTML using the mechanism appropriate to the URI naming
1206 strategy.</p>
1208 </div>
1210 <div class='section'>
1211 <p class='title'>Example: serving the A&amp;A vocabulary</p>
1213 <p>While <span class='cite'>sauermann08</span> discusses the design of
1214 the URIs naming concepts, it says little about the mechanics of making
1215 these available on the web. We refer vocabulary publishers to the
1216 recipe advice contained in <span class='cite'>berrueta08</span>, which
1217 we illustrate here in the case of the <em>hash URI</em> strategy.</p>
1219 <p>The A&amp;A vocabulary has the namespace <span
1220 class='url'>@BASEURI@/AAkeys</span>. In accordance with the above
1221 guidelines, this namespace URI is dereferenceable, and if you enter
1222 the URI into a web browser, you will end up at a page describing the
1223 vocabulary. The way this works can be illustrated by using
1224 <code>curl</code> to dereference the URI (URIs are cropped for legibility):</p>
1225 <pre>% curl http://[...]/rdf/AAkeys
1226 HTTP/1.1 303 See Other
1227 Date: Thu, 08 May 2008 14:07:12 GMT
1228 Server: Apache
1229 Location: http://[...]/rdf/vocabularies-2008-05-08/AAkeys/AAkeys.html
1230 Connection: close
1231 Content-Type: text/html; charset=utf-8
1233 &lt;title&gt;Redirected&lt;/title&gt;
1234 &lt;p&gt;See &lt;a href='http://[...]/rdf/vocabularies-2008-05-08/AAkeys/AAkeys.html'
1235 &gt;elsewhere&lt;/a&gt;&lt;/p&gt;
1236 </pre>
1237 <p>The server has responded to the HTTP GET for the URI with a 303
1238 response, and a <code>Location</code> header, pointing to the HTML
1239 representation of this thing. In this example, the server has
1240 included a brief HTML explanation in case a human happens to see this response.</p>
1242 <p>If we instead request an RDF representation, by stating a desired
1243 MIME type in the HTTP <code>Accept</code> header, we get a slightly
1244 different response:</p>
1245 <pre>% curl --head -H accept:text/turtle http://[...]/rdf/AAkeys
1246 HTTP/1.1 303 See Other
1247 Date: Thu, 08 May 2008 14:11:28 GMT
1248 Server: Apache
1249 Location: http://[...]/rdf/vocabularies-2008-05-08/AAkeys/AAkeys.ttl
1250 Connection: close
1251 Content-Type: text/html; charset=iso-8859-1
1252 </pre>
1253 <p>This is also a 303 response, but the <code>Location</code> header
1254 this time points to an RDF file in Turtle syntax, which we can now retrieve normally.</p>
1255 <pre>% curl --include http://[...]/rdf/vocabularies-2008-05-08/AAkeys/AAkeys.ttl
1256 HTTP/1.1 200 OK
1257 Date: Thu, 08 May 2008 14:13:35 GMT
1258 Server: Apache
1259 Content-Type: text/turtle; charset=utf-8
1261 @base &lt;http://[...]/rdf/AAkeys&gt; .
1262 @prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
1263 @prefix dc: &lt;http://purl.org/dc/elements/1.1/&gt; .
1264 @prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
1265 @prefix : &lt;http://www.w3.org/2008/05/skos#&gt; .
1267 &lt;&gt;
1268 dc:created "2008-05-08" ;
1269 dc:title "Vocabulary for Astronomy &amp; Astrophysics Journal keywords (Version wd-1.0)"@en ;
1270 a :ConceptScheme ;
1272 # and so on...
1273 </pre>
1274 <p>Note that the base URI in the returned RDF still refers to the
1275 unversioned concept names.</p>
1277 <p>This behaviour is controlled by (in this case) an Apache
1278 <code>.htaccess</code> file which looks like this:</p>
1279 <pre>AddType application/rdf+xml .rdf
1280 # The MIME type for .n3 should be text/rdf+n3, not application/n3:
1281 # see MIME notes at &lt;http://www.w3.org/2000/10/swap/doc/changes.html&gt;
1282 #
1283 # The MIME type for Turtle is text/turtle, though this has not
1284 # completed its registration: see
1285 # &lt;http://www.w3.org/TeamSubmission/turtle/#sec-mediaReg&gt;
1286 AddType text/rdf+n3 .n3
1287 AddType text/turtle .ttl
1288 # For Charset types, see &lt;http://www.iana.org/assignments/character-sets&gt;
1289 AddCharset UTF-8 .n3
1290 AddCharset UTF-8 .ttl
1292 RewriteEngine On
1293 # This will match the directory where this file is located.
1294 RewriteBase /users/norman/ivoa/vocabularies/rdf
1296 RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
1297 RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ vocabularies-2008-05-08/$1/$1.rdf [R=303]
1299 RewriteCond %{HTTP_ACCEPT} text/rdf\+n3 [OR]
1300 RewriteCond %{HTTP_ACCEPT} application/n3 [OR]
1301 RewriteCond %{HTTP_ACCEPT} text/turtle
1302 RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ vocabularies-2008-05-08/$1/$1.ttl [R=303]
1304 # Any other accept header, including none: make the .html version the default
1305 RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ vocabularies-2008-05-08/$1/$1.html [R=303]
1306 </pre>
1307 <p>These various <code>RewriteRule</code> statements examine the
1308 content of the HTTP <code>Accept</code> header, and return
1309 303-redirections to the appropriate actual resource.</p>
1311 <p>Note that the namespace remains unversioned throughout the
1312 maintenance history of this vocabulary, even though the actual RDF
1313 files being returned might change as labels or relationships are
1314 adjusted. Previous versions of the vocabulary RDF will remain
1315 available, though they will no longer be served by dereferencing the
1316 namespace URL.</p>
1318 </div>
1320 </div>
1323 <div class="section" id='distvocab'>
1324 <p class="title">Example vocabularies (informative)</p>
1326 <p>The intent of having the IVOA adopt SKOS as the preferred format for
1327 astronomical vocabularies is to encourage the creation and management
1328 of diverse vocabularies by competent astronomical groups, so that
1329 users of the VO and related resources can benefit directly and
1330 dynamically without the intervention of the IAU or IVOA. However, we
1331 felt it important to provide several examples of vocabularies in the
1332 SKOS format as part of the proposal, to illustrate their simplicity
1333 and power, and to provide an immediate vocabulary basis for VO
1334 applications.</p>
1336 <p>The vocabularies described below are included, as SKOS files, in
1337 the distributed version of this standard. These vocabularies have
1338 stable URLs, and may be cited and used indefinitely. These
1339 vocabularies will not, however, be developed as part of the
1340 maintenance of this standard. Interested groups, within and outwith
1341 the IVOA, are encouraged to take these as a starting point and absorb
1342 them within existing processes.</p>
1344 <p>The exceptions to this rule are the constellation vocabulary,
1345 provided here mainly for didactic purposes, and the proposed IVOA
1346 Thesaurus, which is being developed as a separate project and whose
1347 aim is to provide a corrected, more user-friendly, more complete, and
1348 updated version of the 1993 IAU thesaurus. Although work on the IVOA
1349 Thesaurus is on-going, the fact that it is largely based on the IAU
1350 thesaurus means that it is already a very useful resource, so a usable
1351 snapshot of this vocabulary will be published with the other
1352 examples.</p>
1354 <p>We provide a set of SKOS files representing the vocabularies which
1355 have been developed, and an example mapping file between the A&amp;A
1356 keywords and the AVM Taxonomy. These vocabularies
1357 have base URIs starting <span class='url'>@BASEURI@</span>, and can be
1358 downloaded at the URL</p>
1359 <blockquote>
1360 <span class='url'>@BASEURI@/@DISTNAME@.tar.gz</span>
1361 </blockquote>
1363 <div class='section' id='vocab-constellation'>
1364 <p class='title'>A Constellation Name Vocabulary</p>
1366 <p>This vocabulary is presented as a simple example of an astronomical vocabulary for a very particular purpose, such as handling constellation information like that commonly encountered in variable star research. For example, <q>SS Cygni</q> is a cataclysmic variable located in the constellation <q>Cygnus</q>. The name of the star uses the genitive form <q>Cygni</q>, but the alternate label <q>SS Cyg</q> uses the standard abbreviation <q>Cyg</q>. Given the constellation vocabulary, all of these forms are recorded together in a computer-manipulatable format. Various incorrect forms should probably be represented in SKOS hidden labels.</p>
1368 <p>The <code>&lt;skos:ConceptScheme&gt;</code> contains a single
1369 <code>&lt;skos:TopConcept&gt;</code>, <q>constellation</q></p>
1371 <center>
1372 <table>
1373 <tr><th bgcolor="#eecccc">XML Syntax</th>
1374 <th width="10"/><th bgcolor="#cceecc">Turtle Syntax</th></tr>
1375 <tr><td/></tr>
1376 <tr>
1377 <td class='rdfxml'>
1378 <pre class='rdfxml'>&lt;skos:Concept rdf:about="#constellation"&gt;
1379 &lt;skos:inScheme rdf:resource=""/&gt;
1380 &lt;skos:prefLabel&gt;
1381 constellation
1382 &lt;/skos:prefLabel&gt;
1383 &lt;skos:definition&gt;
1384 IAU-sanctioned constellation names
1385 &lt;/skos:definition&gt;
1386 &lt;skos:narrower rdf:resource="#Andromeda"/&gt;
1387 ...
1388 &lt;skos:narrower rdf:resource="#Vulpecula"/&gt;
1389 &lt;/skos:Concept&gt;
1390 </pre>
1391 </td>
1392 <td/>
1393 <td class='turtle'>
1394 <pre class='turtle'>&lt;#constellation&gt; a :Concept;
1395 :inScheme &lt;&gt;;
1396 :prefLabel "constellation";
1397 :definition "IAU-sanctioned constellation names";
1398 :narrower &lt;#Andromeda&gt;;
1399 ...
1400 :narrower &lt;#Vulpecula&gt;.
1401 </pre>
1402 </td></tr>
1403 </table></center>
1404 <p>and the entry for <q>Cygnus</q> is</p>
1405 <center><table><tr>
1406 <td class='rdfxml'>
1407 <pre class='rdfxml'>&lt;skos:Concept rdf:about="#Cygnus"&gt;
1408 &lt;skos:inScheme rdf:resource=""/&gt;
1409 &lt;skos:prefLabel&gt;Cygnus&lt;/skos:prefLabel&gt;
1410 &lt;skos:definition&gt;Cygnus&lt;/skos:definition&gt;
1411 &lt;skos:altLabel&gt;Cygni&lt;/skos:altLabel&gt;
1412 &lt;skos:altLabel&gt;Cyg&lt;/skos:altLabel&gt;
1413 &lt;skos:broader rdf:resource="#constellation"/&gt;
1414 &lt;skos:scopeNote&gt;
1415 Cygnus is nominative form; the alternative
1416 labels are the genitive and short forms
1417 &lt;/skos:scopeNote&gt;
1418 &lt;/skos:Concept&gt;
1419 </pre>
1420 </td>
1421 <td width="10"/>
1422 <td class='turtle'>
1423 <pre class='turtle'>&lt;#Cygnus&gt; a :Concept;
1424 :inScheme &lt;&gt;;
1425 :prefLabel "Cygnus";
1426 :definition "Cygnus";
1427 :altLabel "Cygni";
1428 :altLabel "Cyg";
1429 :broader &lt;#constellation&gt;;
1430 :scopeNote """Cygnus is nominative form;
1431 the alternative labels are the genitive and
1432 short forms""" .
1433 </pre>
1434 </td>
1435 </tr></table></center>
1437 <p>Note that SKOS alone does not permit the distinct differentiation
1438 of genitive forms and abbreviations, but the use of alternate labels
1439 is more than adequate enough for processing by VO applications where
1440 the difference between <q>SS Cygni</q>, <q>SS Cyg</q>, and the incorrect form
1441 <q>SS Cygnus</q> is probably irrelevant.</p>
1442 </div>
1444 <div class='section' id='vocab-aa'>
1445 <p class='title'>The Astronomy &amp; Astrophysics Keyword List</p>
1447 <p>Namespace: <span class='url'>@BASEURI@/AAkeys</span>.</p>
1449 <p>This vocabulary is a set of keywords maintained jointly by the
1450 publishers of the journals <em>Astronomy and Astrophysics</em>
1451 (A&amp;A), <em>Monthly Notices of the Royal Astronomical Society</em>
1452 (MNRAS) and the <em>Astrophysical Journal</em> (ApJ). As noted in the
1453 introduction, an analysis of these keywords <span
1454 class='cite'>preitemartinez07</span> indicates that the different
1455 journals are slightly inconsistent with each other; we have rather
1456 arbitrarily used the list from the A&amp;A web site. The intended
1457 usage of the vocabulary is to tag articles with descriptive keywords
1458 to aid searching for articles on a particular topic.</p>
1460 <p>The keywords are organised into categories which have been modelled as
1461 hierarchical relationships.
1462 Additionally, some of the keywords are grouped into collections which
1463 has been mirrored in the SKOS version.
1464 The vocabulary contains no definitions or related links as these are
1465 not provided in the original keyword list, and only a handful of
1466 alternative labels and scope notes that are present in the original
1467 keyword list.</p>
1469 </div>
1471 <div class='section' id='vocab-avm'>
1472 <p class='title'>The AVM Taxonomy</p>
1474 <p>Namespace: <span class='url'>@BASEURI@/AVM</span>.</p>
1476 <p>This vocabulary is published by the IVOA to allow images to be
1477 tagged with keywords that are relevant for the public. It consists of
1478 a set of keywords organised into an enumerated hierarchical structure.
1479 Each term consists of a taxonomic number and a label. There are no
1480 definitions, scope notes, or cross references.</p>
1482 <p>When converting the AVM into SKOS, it was decided to model the
1483 taxonomic number as both a <code>skos:notation</code> and an alternative
1484 label. Since there are duplication of terms, the token for a term consists of
1485 the taxinomical number to avoid ambiguity and to keep the tokens short.
1486 <!--
1487 the full hierarchical location of the term.
1488 Thus, it is possible to distinguish between</p>
1489 <pre>Planet -> Feature -> Surface -> Canyon</pre>
1490 <p>and</p>
1491 <pre>Planet -> Satellite -> Feature -> Surface -> Canyon</pre>
1492 <p>which have the tokens <code>PlanetFeatureSurfaceCanyon</code> and
1493 <code>PlanetSatelliteFeatureSurfaceCanyon</code> respectively.-->
1494 </p>
1496 </div>
1498 <div class='section' id='vocab-ucd1'>
1499 <p class='title'>The UCD1+ Vocabulary</p>
1501 <p>Namespace: <span class='url'>@BASEURI@/UCD</span>.</p>
1503 <p>The UCD standard is an officially sanctioned and managed vocabulary
1504 of the IVOA. The normative document is a simple text file containing
1505 entries consisting of tokens (for example <code>em.IR</code>), a short
1506 description, and usage information (<q>syntax codes</q> which permit
1507 UCD tokens to be concatenated). The form of the tokens implies a
1508 natural hierarchy: <code>em.IR.8-15um</code> is obviously a narrower
1509 term than <code>em.IR</code>, which in turn is narrower than
1510 <code>em</code>.</p>
1512 <p>Given the structure of the UCD1+ vocabulary, the natural
1513 translation to SKOS consists of preferred labels equal to the original
1514 tokens (the UCD1 words include dashes and periods), vocabulary tokens
1515 created using guidelines in <span class='xref'
1516 >practices</span> (for example, "emIR815Um" for
1517 <code>em.IR.8-15um</code>), direct use of the definitions, and the syntax codes
1518 placed in usage documentation: <code>&lt;skos:scopeNote&gt;UCD syntax code: P&lt;/skos:scopeNote&gt;</code></p>
1520 <p>Note that the SKOS document containing the UCD1+ vocabulary does
1521 NOT consistute the official version: the normative document is still
1522 the text list. However, on the long term, the IVOA may decide to make
1523 the SKOS version normative, since the SKOS version contains all of the
1524 information contained in the original text document but has the
1525 advantage of being in a standard format easily read and used by any
1526 application on the semantic web whilst still being usable in the
1527 current ways.</p>
1529 </div>
1531 <div class='section' id='vocab-iau93'>
1532 <p class='title'>The 1993 IAU Thesaurus</p>
1534 <p>Namespace: <span class='url'>@BASEURI@/IAUT93</span>.</p>
1536 <p>The IAU Thesaurus consists of concepts with mostly capitalised
1537 labels and a rich set of thesaurus relationships (<q>BT</q> for
1538 "broader term", <q>NT</q> for <q>narrower term</q>, and <q>RT</q> for
1539 <q>related term</q>). The thesaurus also contains <q>U</q> (for
1540 <q>use</q>) and <q>UF</q> (<q>use for</q>) relationships. In a SKOS
1541 model of a vocabulary these are captured as alternative labels. A
1542 separate document contains translations of the vocabulary terms in
1543 five languages: English, French, German, Italian, and
1544 Spanish. Enumerable concepts are plural (for example <q>SPIRAL
1545 GALAXIES</q>) and non-enumerable concepts are singular
1546 (for example <q>STABILITY</q>). Finally, there are some usage hints like
1547 <q>combine with other</q>, which have been modelled as scope notes.</p>
1549 <p>In converting the IAU Thesaurus to SKOS, we have been as faithful
1550 as possible to the original format of the thesaurus. Thus, preferred
1551 labels have been kept in their uppercase format.</p>
1553 <p>The IAU Thesaurus has been unmaintained since its initial production in
1554 1993; it is therefore significantly out of date in places. This
1555 vocabulary is published for the sake of completeness, and to make the
1556 link between the evolving vocabulary work and any uses of the 1993
1557 vocabulary which come to light. We do not expect to make any future
1558 maintenance changes to this vocabulary, and would expect the IVOAT
1559 vocabulary, based on this one, to be used instead (see <span class='xref'>vocab-ivoat</span>).</p>
1561 </div>
1563 <div class='section' id='vocab-ivoat'>
1564 <p class='title'>Towards an IVOA Thesaurus</p>
1566 <p>While it is true that the adoption of SKOS will make it easy to
1567 publish and access different astronomical vocabularies, the fact is
1568 that there is no vocabulary which makes it easy to jump-start the
1569 use of vocabularies in generic astrophysical VO applications: each of
1570 the previously developed vocabularies has their own limits and
1571 biases. For example, the IAU Thesaurus provides a large number of
1572 entries, copious relationships, and translations to four other languages,
1573 but there are no definitions, many concepts are now only useful for
1574 historical purposes (for example many photographic or historical instrument
1575 entries), some of the relationships are false or outdated, and many
1576 important or newer concepts and their common abbreviations are
1577 missing.</p>
1579 <p>Despite its faults, the IAU Thesaurus constitutes a very extensive
1580 vocabulary which could easily serve as the basis vocabulary once
1581 we have removed its most egregious faults and extended it to cover the
1582 most obvious semantic holes. To this end, a heavily revised IAU
1583 thesaurus is in preparation for use within the IVOA and other
1584 astronomical contexts. The goal is to provide a general vocabulary
1585 foundation to which other, more specialised, vocabularies can be added
1586 as needed, and to provide a good <q>lingua franca</q> for the creation of
1587 vocabulary mappings.</p>
1588 </div>
1589 </div> <!-- End: Example vocabularies -->
1591 <div class='section' id='distmappings'>
1592 <p class='title'>Mapping vocabularies (informative)</p>
1594 <p>Part of the motivation for formalising vocabularies within the VO
1595 is to support <em>mapping between vocabularies</em>, so that an
1596 application which understands, or can natively process, one
1597 vocabulary, can use a mapping to provide at least partial support for
1598 data described using another vocabulary. The SKOS standard describes
1599 a number of properties for expressing such matches, and we anticipate
1600 that we will shortly see explicit mappings between vocabularies,
1601 produced either by vocabulary maintainers, describing the
1602 relationships between their own vocabularies and others, or by third
1603 parties, asserting such relationships as an intellectual contribution
1604 of their own.</p>
1606 <p>The vocabularies distributed in association with this document
1607 include one non-exhaustive mapping mapping file between A &amp; A keywords and the AVM taxonomy, as an example of how such mappings will appear.</p>
1609 <p>Mapping: <span class='url'>@BASEURI@/AAkeys2AVMMapping</span>.</p>
1611 <!--
1612 <p>To show how mappings can be expressed between two vocabularies, we
1613 have provided one example mapping document which maps the concepts in
1614 the A&amp;A Keywords vocabulary to the concepts in the AVM
1615 vocabulary.
1616 All four types of mappings were required.
1617 Since all the mapping relationships have inverse relationships
1618 defined, the mapping document can also be used to infer the set of
1619 mappings from the AVM vocabulary to the A&amp;A keywords.</p>
1621 <p>To provide provenence information about the set of mappings in a
1622 document, Dublin Core metadata is included in the mapping
1623 document.</p>
1625 -->
1627 </div>
1629 <div class="appendices">
1631 <div class="section-nonum" id="bibliography">
1632 <p class="title">References</p>
1633 <?bibliography rm-refs ?>
1634 </div>
1636 <p style="text-align: right; font-size: x-small; color: #888;">
1637 $Revision$ $Date$
1638 </p>
1640 </div>
1642 </body>
1643 </html>


Name Value
svn:keywords Author Date Revision

ViewVC Help
Powered by ViewVC 1.1.26