vocabularies.xml - volute

‹r1076

r1099

Source path: svn/ trunk/ projects/ vocabularies/ doc/ vocabularies.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- Based on template at
     http://www.ivoa.net/Documents/templates/ivoa-tmpl.html -->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:dc="http://purl.org/dc/elements/1.1/"
      xmlns:dcterms="http://purl.org/dc/terms/"
      xml:lang="en" lang="en">

<head>
<title>Vocabularies in the Virtual Observatory</title>
<link rev="made" href="http://nxg.me.uk/norman/#norman" title="Norman Gray"/>
<meta name="author" content="Norman Gray"/>
<meta name="DC.subject" content="IVOA, Virtual Observatory, Vocabulary"/>
<meta property='dcterms:date' content='2008-03-20'/> <!-- initial release -->
<meta name="rcsdate" content="$Date$"/>
<link href="http://www.ivoa.net/misc/ivoa_pr.css" rel="stylesheet" type="text/css"/>
<style type="text/css">
/* make the ToC a little more compact, and without bullets */
div.toc ul { list-style: none; padding-left: 1em; }
div.toc li { padding-top: 0ex; padding-bottom: 0ex; }
li { padding-top: 1ex; padding-bottom: 1ex; }
td { vertical-align: top; }
td.rdfxml { background: #ECC; text-align: left; }
td.turtle { background: #CEC; text-align: left; }
span.userinput { font-weight: bold; }
span.url { font-family: monospace; }
.todo { background: #ff7; }
pre { background: #EEE; padding: 1em; }
pre.rdfxml { background: #ECC; padding: 1em; }
pre.turtle { background: #CEC; padding: 1em; }

/* 'link here' text in section headers */
*.hlink a {
  display: none;
}
*:hover.hlink a {
  display: inline;
  color: #800;
}
</style>
<style type='text/css' media='screen'>
span.rfc2119 { color: #800; }
</style>
<style type='text/css' media='print'>
span.rfc2119 { font-variant: small-caps; }
</style>
</head>

<body>
<div class="head">
<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>

<h1>Vocabularies in the Virtual Observatory<br/>Version @VERSION@</h1>

<h2>IVOA Proposed Recommendation, @RELEASEDATE@</h2>
@DRAFTVERSION@{<p><strong>[EDITORS' DRAFT: $Revision$ $Date$]</strong></p>}

<dl>

<dt>This version</dt>
<dd><span class='url'>@DOCURI@.html</span></dd>

<dt>Latest version</dt>
<dd><span class='url'>http://www.ivoa.net/Documents/latest/Vocabularies.html</span><br/>
and list of <a href='@ISSUESLIST@' >errata</a></dd>

<dt>Previous versions</dt>
<dd><span class='url'>http://www.ivoa.net/Documents/PR/Semantics/Vocabularies-20081104.html</span>
<span class='url'>http://www.ivoa.net/Documents/PR/Semantics/Vocabularies-20080912.html</span>
<span class='url'>http://www.ivoa.net/Documents/PR/Semantics/Vocabularies-20080729.html</span>
<span class='url'>http://www.ivoa.net/Documents/WD/Semantics/vocabularies-20080320.html</span></dd>

<dt>Working Group</dt>
<dd><em><a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics">Semantics</a></em></dd>

<dt>Editors</dt>
<dd>Alasdair J G Gray, University of Manchester, UK<br/>
<a href='http://nxg.me.uk/norman/' >Norman Gray</a>, University of
Leicester / University of Glasgow, UK<br/>
Frederic V Hessman, University of Göttingen, Germany<br/>
Andrea Preite Martinez, INAF, Italy</dd>

<dt>Authors</dt>
<dd>
<span property="dc:creator">Sébastien Derriere</span>,
<span property="dc:creator">Alasdair J G Gray</span>,
<span property="dc:creator">Norman Gray</span>,
<span property="dc:creator">Frederic V Hessman</span>,
<span property="dc:creator">Tony Linde</span>,
<span property="dc:creator">Andrea Preite Martinez</span>,
<span property="dc:creator">Rob Seaman</span> and
<span property="dc:creator">Brian Thomas</span>
</dd>
</dl>
<hr/>
</div>

<div class="section-nonum" id="abstract">
<p class="title">Abstract</p>

<div class="abstract">
<p>This document specifies a standard
format for vocabularies based on the W3C's <em>Resource Description
Framework</em> (RDF) and <em>Simple Knowledge Organization System</em>
(SKOS).  By adopting a standard and simple format, the IVOA will
permit different groups to create and maintain their own specialised
vocabularies while letting the rest of the astronomical community
access, use, and combine them.  The use of current, open standards
ensures that VO applications will be able to tap into resources of the
growing semantic web.  The document provides several examples of
useful astronomical vocabularies.</p>
</div>

</div>

<div class="section-nonum" id="status">
<p class="title">Status of this document</p>

<p>This is an IVOA Proposed Recommendation.
The first release of this document was 2008 March 20.
It is appropriate to reference this document only as a recommended
standard that is under review and which may be changed before it is
accepted as a full recommendation.</p>

<p>A list of current IVOA Recommendations and other technical
documents can be found at
<span class='url' >http://www.ivoa.net/Documents/</span>.</p>

<p class='todo'>This document includes a normative reference to the
W3C SKOS standard <span class='cite'>std:skosref</span>, despite the
fact that, at the time this present PR was published, the SKOS
document had become a W3C Candidate Recommendation and thus formally a <q>work in
progress</q>.  The SKOS document is expected to become a W3C
Recommendation around July 2009, and this document will
remain in the PR state until then, at which point it will be forwarded
to Exec review.  The core part of the SKOS standard which
this standard refers to (that is, the concept schemes, documentation
and intravocabulary relationships) are stable, and are extremely
unlikely to change before Recommendation.</p>

</div>

<div class='section-nonum' id='normativity'>
<p class='title'>Note on conformance</p>

<p>Text within the following document is classified as either
<q>normative</q> or <q>informative</q>.</p>

<p><strong>Normative</strong> text means information that is required
to implement the Recommendation; an implementation of this
Recommendation is conformant if it abides by all the prescriptions
contained in normative text.  <strong>Informative</strong> text is
information provided to clarify or illustrate a requirement but which
is not required for conformance.</p>

<p>The sections and subsections of this Recommendation are labeled,
after the section heading, to specify whether they are normative or
informative.  If a subsection is not labeled, it has the same
normativity as its parent section.  References are normative if they
are referred to within normative text.</p>

<p>Within normative sections, the key words
<span class='rfc2119'>must</span>,
<span class='rfc2119'>must not</span>,
<span class='rfc2119'>required</span>,
<span class='rfc2119'>shall</span>,
<span class='rfc2119'>shall not</span>,
<span class='rfc2119'>should</span>,
<span class='rfc2119'>should not</span>,
<span class='rfc2119'>recommended</span>,
<span class='rfc2119'>may</span>, and
<span class='rfc2119'>optional</span>
in this document are to be interpreted as described in
<span class='cite'>std:rfc2119</span>.</p>

</div>

<div class='section-nonum'>
<p class='title'>Acknowledgments</p>

<p>We would like to thank the members of the IVOA semantic working
group for many interesting ideas and fruitful discussions, and Antoine
Isaac of the SKOS WG for notes on SKOS conformance.</p> 
</div>

<h2><a id="contents" name="contents">Table of Contents</a></h2>
<?toc?>

<hr/>

<div class="section" id="introduction">
<p class="title">Introduction (informative)</p>

<div class="section" id='astrovocab'>
<p class="title">Vocabularies in astronomy</p>

<p>Astronomical information of relevance to the Virtual Observatory
(VO) is not confined to quantities easily expressed in a catalogue or
a table.
Fairly simple things such as position on the sky, brightness in some
units, times measured in some frame, redshifts, classifications or
other similar quantities are easily manipulated and stored in VOTables
and can currently be identified using IVOA Unified Content Descriptors
(UCDs) <span class="cite">std:ucd</span>.
However, astrophysical concepts and quantities use a wide variety of
names, identifications, classifications and associations, most of
which cannot be described or labelled via UCDs.</p>


<p>There are several basic forms of organised semantic knowledge
of potential use to the VO.  Informal <q>folksonomies</q> are at one
extreme, and are a very lightly coordinated collection of labels
chosen by users.  
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;
vocabularies are primarily associated with searching and browsing
tasks.  
At the other extreme are <q>ontologies</q>, where the domain
is formally captured in a set of logical classes, typically related in
a subclass hierarchy.  More formal definitions are presented later in
this document.
</p>

<p>An astronomical ontology is necessary if we are to have a computer
(appear to) <q>understand</q> something of the domain.
There has been some progress towards creating an ontology of
astronomical object types <span
class="cite">std:ivoa-astro-onto</span> to meet this need.
However there are distinct use cases for letting human users find
resources of interest through search and navigation of the information space.
The most appropriate technology to meet these use cases derives from
the Information Science community, namely that of <em>controlled
vocabularies, taxonomies and thesauri</em>.
In the present document, we do not distinguish between controlled
vocabularies, taxonomies and thesauri, and use the term
<em>vocabulary</em> to represent all three.
</p>

<p>One of the best examples of the need for a simple vocabulary within
the VO is VOEvent <span class="cite">std:voevent</span>, the VO
standard for supporting rapid notification of astronomical events.
This standard requires some formalised indication of what a published
event is <q>about</q>, in a formalism which can be used straightforwardly
by the developer of relevant services.  See <span class='xref'
>usecases</span> for further discussion.</p>

<p>A number of astronomical vocabularies have been created, with a
variety of goals and intended uses. Some examples are detailed below. </p>

<ul>

<li>The <em>Second Reference Dictionary of the Nomenclature of
Celestial Objects</em> <span class="cite">lortet94</span>, <span
class="cite">lortet94a</span> contains 500 paper pages of astronomical
nomenclature</li>

<li>For decades professional journals have used a set of reasonably
compatible keywords to help classify the content of whole articles.
These keywords have been analysed by Preite Martinez &amp; Lesteven
<span class="cite">preitemartinez07</span>, who derived a
set of common keywords constituting one of the potential bases for a
fuller VO vocabulary.  The same authors also attempted to derive a set
of common concepts by analysing the contents of abstracts in journal
articles, which should comprise a list of tokens/concepts more
up-to-date than the old list of journal keywords.  A similar but less
formal attempt was made by Hessman <span class='cite'>hessman05</span>
for the VOEvent working group, resulting in a similar list.</li>

<li>Astronomical databases generally use simple sets of keywords
– sometimes hierarchically organised – to help users make queries.
Two examples from very
different contexts are the list of object types used in the <a
href="http://simbad.u-strasbg.fr">Simbad</a> database and the search
keywords used in the educational Hands-On Universe image database
portal.</li>

<li>The Astronomical Outreach Imagery (AOI) working group has created
a simple taxonomy for helping to classify images used for educational
or public relations <span class="cite">std:avm</span>.  See
<span class='xref'>vocab-avm</span>.</li>

<!--
<li>The Hands-On Universe project (see <span class='url'
>http://sunra.lbl.gov/telescope2/index.html</span>) has maintained a
public database of images for use by the general public since the
1990s. The images are very heterogeneous, since they are gathered from
a variety of professional, semi-professional, amateur, and school
observatories, so a simple taxonomy is used to facilitate browsing
by the users of the database.</li>
-->

<li>In 1993, Shobbrook and Shobbrook published an Astronomy Thesaurus
endorsed by the IAU <span class='cite' >shobbrook93</span>.  This
collection of nearly 3000 terms, in five languages, is a valuable
resource, but has seen little use in recent years.  Its very size,
which gives it expressive power, is a disadvantage to the extent that
it is consequently hard to use.  See <span class='xref'>vocab-iau93</span>.</li>

<li>The VO's Unified Content Descriptors <span class='cite'
>std:ucd</span> (UCD) constitute the main controlled vocabulary of the
IVOA and contain some taxonomic information. However, UCD has some
features which supports its goals, but which make it difficult to use
beyond the present applications of labelling VOTables: firstly, there
is no standard means of identifying and processing the contents of the
text-based reference document; secondly, the content cannot be openly
extended beyond that set by a formal IVOA committee without going
through a laborious and time-consuming negotiation process of
extending the primary vocabulary itself; and thirdly, the UCD
vocabulary is primarily concerned with data types and their
processing, and only peripherally with astronomical objects (for
example, it defines formal labels for RA, flux, and bandpass, but does
not mention the Sun).  See <span class='xref'>vocab-ucd1</span>.</li>

</ul>
</div>

<div class='section' id='usecases'>
<p class='title'>Use-cases, and the motivation for formalised vocabularies</p>

<p>The most immediate high-level motivation for this work is the
requirement of the VOEvent standard <span class='cite'
>std:voevent</span> for a controlled vocabulary usable in the
VOEvent's <code>&lt;Why/&gt;</code> and <code>&lt;What/&gt;</code>
elements, which describe what
sort of object the VOEvent packet is describing, in some broadly
intelligible way.  For example a <q>burst</q> might be a gamma-ray burst
due to the collapse of a star in a distant galaxy, a solar flare, or
the brightening of a stellar or AGN accretion disk, and having an
explicit list of vocabulary terms can help guide the event publisher
into using a term which will be usefully precise for the event's
consumers.  A free-text label can help here (which brings us into the
domain sometimes referred to as folksonomies), but the astronomical
community, with a culture sympathetic to international agreement, can
do better.</p>

<p>This standard establishes a set of conventions for
the creation, publication, use, and manipulation of
astronomical vocabularies within the Virtual Observatory, based upon
the W3C's SKOS standard.  We include as appendices to this standard
formalised versions of a number of existing vocabularies, encoded as
SKOS vocabularies <span class="cite">std:skosref</span>.</p>

<p>Specific use-cases include the following.</p>
<ul>
<li>A user wishes to process all events concerning supernovae, which
means that an event concerning a type 1a supernova must be understood to be
relevant. [This supports a system working autonomously, filtering
incoming information.]</li>

<li>A user is searching an archive of VOEvents for microlensing
events, and retrieves a large number of them; the search interface may
then prompt them to narrow their search using one of a set of terms
including, say, binary lens events. [This supports so-called <q>semantic
search</q>, providing semantic support to an interface which is in turn
supporting a user.]</li>

<li>A user wishes to search for resources based on the
journal-supported keywords in a paper; they might either initiate this by
hand, or have this done on their behalf by a tool which can extract
the keywords from a PDF.  The keywords are in the A&amp;A vocabulary,
and mappings have been defined between this vocabulary and others,
which means that the query keywords are translated automatically
into those appropriate for a search of an outreach image database
(everyone likes pretty pictures), the VO Registry, a set of Simbad
object types, and one or more concepts in more formal ontologies.  The
search interface is then able to support the user browsing up and down
the AVM vocabulary, and a specialised Simbad tool is able to take
over the search, now it has an appropriate starting place. [This
supports interoperability, building on the investments which
institutions and users have made in existing vocabularies.]</li>

<li>A user receives a VOTable of results from a VO application – for
example a catalogue of objects or observations – and wants to search a
database of old FITS files for potential matches.  Because the UCDs
labeling the columns of the tables are expressed in well-documented
SKOS, both the official descriptions of the UCDs and their semantic
matches to a variety of other plain-text vocabularies (such as the IAU
or AVM thesauri) are available to the VO application, providing a basis
for massive searches for all kinds of FITS keyword values.</li>

</ul>

<p>The goal of this standard is to show how vocabularies can be easily
expressed in an interoperable and computer-manipulable format, and the
first normative section of this Recommendation (namely section <span
class='xref'>publishing</span>) contains requirements and suggestions
intended to promote this.  In the other normative section (<span
class='xref'>distvocab</span>), we include four example vocabularies
that have previously been expressed using non-standardized formats –
namely the A&amp;A keyword list, the IAU thesaurus and AVM taxonomy,
and UCD1.  These are included as illustrations of how simple it is to
publish them in SKOS, without losing any of the information of the
original source vocabularies.</p>

<p>It is not a goal of this standard, as it is not a goal of SKOS, to
produce knowledge-engineering artefacts which can support elaborate
machine reasoning – the use-cases above are broadly concerned with
searching for data, rather than representing the data itself, and for
this the looser semantics of a thesaurus are more appropriate than the
formal (<q>is-a</q>) semantics of an ontology.  More elaborate artefacts would be
very valuable, but require much more expensive work on ontologies.  As
the supernova use-case above illustrates, even simple vocabularies can
support useful machine reasoning.</p>

<p>It is also not a goal of this standard to produce new vocabularies,
or substantially alter existing ones; instead, the vocabularies
included below in section <span class='xref'>distvocab</span> are directly
and mechanically 
derived from existing vocabularies (the exceptions are the IVOAT
vocabulary, which is ultimately intended to be a significant update to
the IAU-93 original, and the constellations vocabulary, which is
intended to be purely didactic).  It therefore follows that the ambiguities,
redundancies and incompleteness of the source vocabularies are
faithfully represented in the distributed SKOS vocabularies.  We hope
that this formalisation process will create greater visibility and
broader use for the various vocabularies, and that this will guide the
maintenance efforts of the curating groups.</p>


<p>The reason for both of these limitations is that vocabularies are
extremely expensive to produce, maintain and deploy, and we must
therefore rely on such vocabularies as have been developed, and
attached as metadata to resources, by others.  Such vocabularies are
less rich or less coherent than we might prefer, but they are widely enough
deployed to be useful.  We hope that the set of example vocabularies
we have provided will build on this deployment, by providing material
which is useful out of the box.</p>

</div>

<div class="section" id='formalising'>
<p class="title">Formalising and managing multiple vocabularies</p>

<p>We find ourselves in the situation where there are multiple
vocabularies in use, describing a broad range of resources of interest
to professional and amateur astronomers, and members of the public.
These different vocabularies use different terms and different
relationships to support the different constituencies they cater for.
For example, <q>delta Sct</q> and <q>RR Lyr</q> are terms one would
find in a vocabulary aimed at professional astronomers, associated
with the notion of <q>variable star</q>; however one would
<em>not</em> find such technical terms in a vocabulary intended to
support outreach activities.</p>

<p>One approach to this problem is to create a single consensus
vocabulary, which draws terms from the various existing vocabularies
to create a new vocabulary which is able to express anything its users
might desire.  The problem with this is that such an effort would be
very expensive, both in terms of time and effort on the part of those
creating it, and to the potential users, who have to learn
to navigate around it, recognise the new terms, and who have to be
supported in using the new terms correctly (or, more often,
incorrectly).</p>

<p>The alternative approach to the problem is to evade it, and this is
the approach taken in this document.  Rather than deprecating the
existence of multiple overlapping vocabularies, we embrace it,
help interest groups formalise as many of them as are appropriate, and
standardise the process of formally declaring the relationships between
them.  This means that:</p>
<ul>
<li>The various vocabularies are allowed to evolve separately, on
their own timescales, managed either by the IVOA, individual working
groups within the IVOA, or by third parties;</li>

<li>Specialised vocabularies can be developed and maintained by the
community with the most knowledge about a specific topic, ensuring
that the vocabulary will have the most appropriate breadth, depth, and
precision;</li>

<li>Users can choose the vocabulary or combination of vocabularies most
appropriate to their situation, either when annotating resources, or
when querying them; and</li>

<li>We can retain the previous investments made in vocabularies by
users and resource owners.</li>

</ul>


</div>

</div>

<div class='section' id='skos'>
<p class='title'>SKOS-based vocabularies (informative)</p>

<p>In this section, we introduce the concepts of SKOS-based
vocabularies, and the technology of mapping between them.  We describe
some additional requirements for IVOA vocabularies in the next
section, <span class='xref' >publishing</span>.</p>

<div class="section" id='vocab'>
<p class="title">Selection of the vocabulary format</p>

<p>After extensive online and face-to-face discussions, the authors have
brokered a consensus within the IVOA community that 
formalised vocabularies should be published at least in SKOS (Simple Knowledge
Organization System) format, a W3C draft standard application of RDF to the
field of knowledge organisation <span
class="cite">std:skosref</span>.  SKOS draws on long experience
within the Library and Information Science communities, to address a
well-defined set of problems to do with the indexing and retrieval of
information and resources; as such, it is a close match to the problem
this document is addressing.  For more detailed introductory
discussion, see the SKOS Primer <span class='cite'>isaac08</span>.</p>

<p>ISO 5964 <span class='cite' >std:iso5964</span> defines a number of
the relevant terms (ISO 5964:1985=BS 6723:1985; see also <span
class='cite' >std:bs8723-1</span> and <span class='cite'
>std:z39.19</span>), and some of the (lightweight) theoretical
background.  The only technical distinction relevant to this document
is that between vocabulary and thesaurus: BS-8723-1 defines a
controlled vocabulary as a</p>
<blockquote>
prescribed list of terms or headings each one having an assigned meaning 
[noting that <q>Controlled vocabularies are designed for use in
classifying or indexing documents and for searching them.</q>]
</blockquote>
<p>and a thesaurus as a</p>
<blockquote>
Controlled vocabulary in which concepts are represented by preferred
terms, formally organised so that paradigmatic relationships between
the concepts are made explicit, and the preferred terms are
accompanied by lead-in entries for synonyms or quasi-synonyms.
<!-- NOTE:
The purpose of a thesaurus is to guide both the indexer and the
searcher to select the same preferred term or combination of preferred
terms to represent a given subject. -->
(BS-8723-1, sect. 2.39)
</blockquote>
<p>with a similar definition in ISO-5964 sect. 3.16.  The
<q>vocabularies</q> discussed in this document are therefore more
properly termed thesauri, but we will retain the term 'vocabulary'
since it is marginally more familiar in the astronomical community.</p>

<p>The paradigmatic relationships in question are those relating a
term to a <q>broader</q>, <q>narrower</q> or more generically
<q>related</q> term.  These notions have an operational definition:
any resource retrieved as a result of a search on a given term will
also be retrievable through a search on that term's <q>broader
term</q> (<q>narrower</q> is a simple inverse, so that for any pair of
terms, if <code>A skos:broader B</code>, then <code>B skos:narrower
A</code>; a term may have multiple narrower and broader terms).  This
is not a subsumption relationship, as there is no implication that the
concept referred to by a narrower term is of the same <em>type</em> as
a broader term.  For example, the term <q>Comet</q> might have
<q>Nucleus</q> as a narrower term, but this does not imply that a
nucleus is a subclass of comet.  Further, the <code>skos:broader</code> and
<code>skos:narrower</code> relationships are not transitive (that is,
declaring that <code>A skos:broader B</code> and <code>B
skos:broader C</code> does not imply that <code>A skos:broader
C</code>).  However the SKOS standard includes the notions of
<code>skos:broaderTransitive</code> and
<code>skos:narrowerTransitive</code> relations for the subset of
vocabularies and systems which would find these useful.</p>

<p>Thus a vocabulary (SKOS or otherwise) is not an
ontology.  It has lighter and looser semantics than an
ontology, and is specialised for the restricted case of resource
retrieval.  Those interested in ontological analyses can easily
transfer the vocabulary relationship information from SKOS to a formal
ontological format such as OWL <span class='cite' >std:owl</span>.</p>

<p>The purpose of a thesaurus is to help users find resources they
might be interested in, be they library books, image archives, or VOEvent
packets.</p>

</div>

<div class='section' id='skos-format'>
<p class='title'>Content and format of a SKOS vocabulary</p>

<p>A published vocabulary in SKOS format consists of a set of
<q>concepts</q> – an example concept capturing the
vocabulary information about spiral galaxies is provided in the <a
href='#figexample' >Figure below</a>, with the RDF shown in both
RDF/XML <span class='cite' >std:rdfxml</span> and Turtle notation <span
class='cite' >std:turtle</span> (Turtle is similar to the more
informal <em>Notation3</em>).  The elements of a concept are detailed
below.</p>

<center>
<p><a name='figexample' >Figure: examples of a SKOS vocabulary</a></p>
<table>
<tr>
<th class='rdfxml'>XML Syntax</th>
<th width="10"/>
<th class='turtle'>Turtle Syntax</th>
</tr>
<tr><td/></tr>
<tr> 
<td class='rdfxml'>
  <pre class='rdfxml'>
&lt;skos:Concept rdf:about="#spiralGalaxy"&gt;
  &lt;skos:prefLabel lang="en"&gt;
    spiral galaxy
  &lt;/prefLabel&gt;
  &lt;skos:prefLabel lang="de"&gt;
    Spiralgalaxie
  &lt;/prefLabel&gt;
  &lt;skos:notation rdf:datatype="#_notation"&gt;
    5.1.1
  &lt;/skos:notation&gt;
  &lt;skos:altLabel lang="en"&gt;
    spiral nebula
  &lt;/skos:altLabel&gt;
  &lt;skos:hiddenLabel lang="en"&gt;
    spiral glaxy
  &lt;/hiddenLabel&gt;
  &lt;skos:definition lang="en"&gt;
    A spiral galaxy is defined here following
    the definition in ...
  &lt;/skos:definition&gt;
  &lt;skos:scopeNote lang="en"&gt;
    The Sa/Sc/Sd subtypes of Spiral
    galaxies are not represented here,
    and should be noted in image comments.
  &lt;/skos:scopeNote&gt;
  &lt;skos:narrower
    rdf:resource="#barredSpiralGalaxy"/&gt;
  &lt;skos:broader
    rdf:resource="#galaxy"/&gt;
  &lt;skos:related
    rdf:resource="#spiralArm"/&gt;
&lt;/skos:Concept&gt;
&lt;!-- .... --&gt;
&lt;rdf:Description rdf:about="#_notation"&gt;
  &lt;dc:description&gt;
    Notation described in foo.pdf
  &gt;/dc:description&gt;
&lt;/rdf:Description&gt;
</pre>
</td>
<td/> 
<td class='turtle'>
<pre class='turtle'>
&lt;#spiralGalaxy&gt; a skos:Concept;
  skos:prefLabel
    "spiral galaxy"@en, 
    "Spiralgalaxie"@de;
  skos:notation "5.1.1"^^&lt;#_notation&gt;;
  skos:altLabel "spiral nebula"@en;
  skos:hiddenLabel "spiral glaxy"@en;
  skos:definition """ A spiral galaxy is defined here
    following the definition in ..."""@en;
  skos:scopeNote """The Sa/Sc/Sd subtypes of Spiral
    galaxies are not represented here,
    and should be noted in image comments."""@en;
  skos:narrower &lt;#barredSpiralGalaxy&gt;;
  skos:broader &lt;#galaxy&gt;;
  skos:related &lt;#spiralArm&gt; .


# ...
&lt;#_notation&gt; dc:description
  "Notation described in foo.pdf".
</pre>
</td>
</tr> 
</table>
</center> 

<p>A SKOS vocabulary is essentially a list of SKOS 'concepts', plus
some metadata.  Each SKOS concept has some or all of the following
features, of which only the first two are required.</p>

<ul> 

<li>A single URI representing the concept, mainly for use by computers
(that is, it is not required to be human-readable).  This is a
syntactic requirement.</li>

<li>A single prefered label in each supported language of the
vocabulary, for use by humans.  This is required.</li>

<li>Alternative labels which applications may encounter,
whether simple synonyms or commonly-used aliases such as
<q>GRB</q> for <q>gamma-ray burst</q>, or <q>Spiral nebula</q> for
<q>spiral galaxies</q>.</li>

<li>Hidden labels which capture terms which are sometimes
used for the corresponding concept, but which are deprecated in some
sense.  Very common mis-spellings might arguably be included here, but
there is no clear best practice.</li>

<li>A <q>notation</q> code (such as <code>5.1.1</code> for
spiral galaxies within the AVM), used to uniquely identify a
concept within a given scheme.  If this is used, then a you should
indicate which notation is being used by indicating a ‘datatype’ for
the notation, as discussed in Section 6 of <span
class='cite'>std:skosref</span>.  This is less onerous than it sounds:
although this may be defined as a full XML Schema datatype, as
illustrated here it need be nothing more sophisticated
than an otherwise unused fragment identifier elsewhere in the
document, which indicates the notation unambiguously.  For our
purposes, this serves mostly as documentation, though precision here
means that the information is available to a vocabulary processor if
it is able to make use of it.</li>

<li>A definition for the concept, where one exists in the original
vocabulary, to give a meaning for the term.  This need not be extensive,
but it should indicate to someone using the vocabulary what the
Concept is intended to refer to, and how precise it is
expected to be.</li>

<li>A scope note to further clarify a definition, or the usage of the
concept.  While the definition explains the meaning of the term in
some abstract sense, the scope note provides practical usage hints to
a user of the vocabulary.  For example, a scope note might say ‘This
is not to be confused with...’ or ‘In the case X, use term Y’.</li>

<li>A concept may also be involved in any number of relationships
with other concepts. The types of relationships are
<ul>
<li>Narrower or more specific concepts, for example a link to the concept
representing a <q>barred spiral galaxy</q>.</li>
<li>Broader or more general concepts, for example a link to the token
representing galaxies in general.</li>
<li>Related concepts, for example a link to the token representing spiral
arms of galaxies (note this relationship does not say that spiral galaxies have spiral
arms – that would be ontological information of a higher order which
is beyond the requirements for information stored in a vocabulary).</li>
</ul>
</li>
</ul>

<p>Only the URI and preferred label are required; all of the remaining
features are optional (see also <span class='xref'>pubreq</span>).  Although including these features is desirable in a
newly-developed vocabulary, if one is converting an existing
vocabulary to SKOS form, it may not be feasible or desirable to add
missing information.  For example, the vocabularies described in
section <span class='xref'>distvocab</span> were derived from existing
term lists which had almost none of this value-adding apparatus.</p>

<p>In addition to the information about a single concept, a vocabulary
can contain information to help users navigate its structure and
contents:</p>
<ul>
<li>The <q>top concepts</q> of the vocabulary, i.e. those that occur
at the top of the vocabulary hierarchy defined by the broader/narrower
relationships, can be explicitly stated to make it easier to navigate
the vocabulary.</li>

<li>Concepts that form a natural group can be defined as being members
of a <q>collection</q>.</li>

<li>Versioning information can be added using change notes.</li>

<li>Additional metadata about the vocabulary, for example indicating
the publisher, must be documented using the Dublin Core metadata set
<span class='cite' >std:dublincore</span>, <span
class='cite'>std:pubguide</span>.  At a minimum, the vocabulary's
<code>skos:ConceptScheme</code> should be annotated with DC Terms <q>title</q>,
<q>creator</q>, <q>description</q> and <q>created</q>.</li>

<li>The SKOS standard describes a number of <q>documentation
properties</q>; these should be used to document provenance of and
changes to vocabulary terms.</li>

<li>A set of mappings between the concepts in different vocabularies 
see section <span class='xref'>skos-relationships</span></li>
</ul>

<p>Note, the set of mappings between vocabularies has the potential to be
circular or create inconsistencies, though this is probably reasonably
unlikely in fact.  This is in principle out of the
control of the vocabulary authors, since vocabularies do not contain
mappings, and so this can only be detected dynamically by applications
which use the vocabularies.</p>

<p>The DC Terms namespace is <code>http://purl.org/dc/terms/</code>,
as opposed to the older, and now somewhat deprecated, DC Elements
namespace <code>http://purl.org/dc/elements/1.1/</code> <span
class='cite'>std:dublincore</span>, <span
class='cite'>std:pubguide</span>.  Also, note that the value of the DC
Terms <code>dc:creator</code> property is an object, not a literal;
and the value of the <code>dc:created</code> property is a literal
string conforming to the W3C profile of ISO 8601 <span
class='cite'>std:w3cdtf</span>.  This standard does not prescribe the
content of the (object) value of the <code>dc:creator</code> property,
but properties from the FOAF namespace are good choices.</p>

<p>Thus a suitable <code>skos:ConceptScheme</code> declaration might
be:</p>
<center>
<p><a name='figexample' >Figure: examples of a SKOS vocabulary</a></p>
<table>
<tr>
<th class='rdfxml'>XML Syntax</th>
<th width="10"/>
<th class='turtle'>Turtle Syntax</th>
</tr>
<tr><td/></tr>
<tr> 
<td class='rdfxml'>
<pre class='rdfxml'>
&lt;rdf:RDF xmlns:dc="http://purl.org/dc/terms/"
     xmlns:foaf="http://xmlns.com/foaf/0.1/"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns="http://www.w3.org/2004/02/skos/core#"&gt;
  &lt;ConceptScheme rdf:about=""&gt;
    &lt;dc:created&gt;2008-05-08&lt;/dc:created&gt;
    &lt;dc:creator&gt;
      &lt;rdf:Description&gt;
        &lt;foaf:name&gt;The IVOA Semantics
          Working Group&lt;/foaf:name&gt;
      &lt;/rdf:Description&gt;
    &lt;/dc:creator&gt;
    &lt;dc:description xml:lang="en"&gt;This is a list
      of keywords ...&lt;/dc:description&gt;
    &lt;dc:title xml:lang="en"&gt;Vocabulary for ...&lt;/dc:title&gt;
  &lt;/ConceptScheme&gt;
  &lt;!-- etc --&gt;
&lt;/rdf:RDF&gt;
</pre>
</td>
<td/>
<td class='turtle'>
<pre class='turtle'>
@prefix dc: &lt;http://purl.org/dc/terms/&gt; .
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
@prefix : &lt;http://www.w3.org/2004/02/skos/core#&gt; .

&lt;&gt; a :ConceptScheme ;
  dc:created "2008-05-08" ;
  dc:title "Vocabulary for ..."@en ;
  dc:creator [
    foaf:name
      "The IVOA Semantics Working Group"
  ];
  dc:description 
    "This is a list of keywords ..."@en;
  # etc
</pre>
</td>
</tr>
</table>
</center>

</div>


<div class='section' id='skos-relationships'>
<p class='title'>Mapping relationships between vocabularies</p>

<p>There already exist several vocabularies in the domain of astronomy.
Instead of attempting to replace all these existing vocabularies,
which have been developed to achieve different aims and user groups,
we embrace them.
This requires a mechanism to relate the concepts in the different
vocabularies.</p>

<p>Part of the SKOS working draft standard <span class='cite'>std:skosref</span>
allows a concept in one vocabulary to be related to a concept in
another vocabulary.
There are four types of relationship provided to capture the
relationships between concepts in vocabularies, which are similar to
those defined for relationships between concepts within a single
vocabulary.
The types of mapping relationships are as follows.</p>


<ul>

<li>
Equivalence between concepts, i.e. the concepts in the different
vocabularies refer to the same real world entity.
This is captured with the RDF statement
<blockquote>
<code>AAkeys:#Cosmology skos:exactMatch avm:#Cosmology</code>
</blockquote>
which states that the cosmology concept in the A&amp;A Keywords is the
same as the cosmology concept in the AVM.
(Note the use of an external namespaces <code>AAkeys</code> and
<code>avm</code> which must be defined within the document.)
</li>

<li>
Broader concept, i.e. there is not an equivalent concept but there is
a more general one.
This is captured with the RDF statement
<blockquote>
  <code>AAkeys:#Moon skos:broadMatch avm:PlanetSatellite</code>
</blockquote>
which states that the AVM concept <q>Planet Satellite</q> is a more general
term than the A&amp;A Keywords concept <q>Moon</q>.
</li>

<li>
Narrower concept, i.e. there is not an equivalent concept but there is
a more specific one.
This is captured with the RDF statement 
<blockquote>
  <code>AAkeys:#IsmClouds skos:narrowMatch 
  avm:#NebulaAppearanceDarkMolecularCloud</code>
</blockquote>
which states that the AVM concept <q>Nebula Appearance Dark Molecular
Cloud</q> is more specific than the A&amp;A Keywords concept <q>ISM Clouds</q>.  
</li>

<li>
Related concept, i.e. there is some form of associative relationship.
This is captured with the RDF statement 
<blockquote>
  <code>AAkeys:#BlackHolePhysics skos:relatedMatch 
avm:#StarEvolutionaryStageBlackHole</code> 
</blockquote>
which states that the A&amp;A Keywords concept <q>Black Hole Physics</q> has
an association with the AVM concept <q>Star Evolutionary Stage Black Hole</q>.
</li>

</ul>

<p>The semantic mapping relationships have certain properties.
The broadMatch relationship has the narrowMatch relationship as its
inverse and the exactMatch and relatedMatch relationships are
symmetrical.
The consequence of these properties is that if you have a mapping from
concept <code>A</code> in one vocabulary to concept <code>B</code> in
another vocabulary then you can infer a mapping from concept
<code>B</code> to concept <code>A</code>.
</p>

<p class='todo'>At the time of writing, the SKOS document is still a
working draft, and may or may not end up with support for mappings in
the core document rather than in a companion document.  This section
of this Working Draft, and other references to mappings below, should
therefore be considered as current best practice and could be updated
in a subsequent version of this document once the SKOS document has
become a standard.</p>

</div>

<div class='section' id='vocabversions'>
<p class='title'>Vocabulary versions</p>

<p>The document <span class='cite'>kendall08</span> discusses good
practice for managing RDF vocabularies.  At the time of writing (2008
May) this is still an editor's draft, and it itself notes that good
practice in this area is not yet fully stable, so our recommendations
here are necessarily tentative, and in some places restricted to the
relatively small vocabularies (100s to 1000s of terms) we expect to
encounter in the VO.  We expect to adjust or enhance this advice in
future editions of this Recommendation, as best practice evolves, or
as we gain more experience with the relevant vocabularies.</p>

<p>We must distinguish between versions of a vocabulary, and versions
of the description of a vocabulary.  In the former case, we are
concerned with the presence or absence of certain concepts, such as
<q>star</q> or <q>GRB</q>, and expect that there will be some
reasonably stable relationship between the concept URI and the
real-world concept it refers to.  In the latter case, we are concerned
with the technicalities of associating a concept URI with its
labels, its description, and with other related concept URIs.  While
it is true that there are epistemological commitments involved in the
simple act of naming (and the terms <q>GRB</q> and <q>planet</q>
remind us that there is knowledge implicit within a name), it is the
latter case that generally represents the <em>knowledge</em> we have
of an object, and it is this knowledge which we must version.  For
example, the concept of <q>planet</q> is a stable one, and so should
not be versioned, but the <em>definition</em> of a planet was changed
by the IAU in 2006, so that the description of a vocabulary term such
as <q>planet</q> would have changed then, and should be versioned.</p>

<p>In consequence, <em>the concept URIs should not carry
version information</em>.  The partial exception to this is when a
vocabulary undergoes a major restructuring, as a result of the terms
in it becoming significantly incoherent – for example, we might
imagine the IAU93 thesaurus being updated to form an IAU 200x
thesaurus – but in this case we should regard the result as a new
vocabulary, rather than simply an adjusted version of an old one.</p>

<p>All the terms in the SKOS vocabulary appear in an unversioned
namespace, and once in the vocabulary they are not removed <span
class='cite'>kendall08</span>.  Successive versions of the vocabulary
description describe the vocabulary terms as <q>unstable</q>, <q>testing</q>,
<q>stable</q> or <q>deprecated</q>.</p>
<!-- there seems to be no
     discussion of this in a SKOS document, as opposed to commentary on
     SKOS -->

<p>The Dublin Core namespaces are managed in a similar way <span
class='cite'>dc:namespaces</span>.  The namespace URIs, which act as
common prefixes to the DC terms, and which are defined using a <q>hash
URI</q> strategy, in RDF terms, have no version numbers, so that 
the namespace for the DC terms vocabulary is <span
class='url'>http://purl.org/dc/terms/</span>.  Terms such as <span
class='url'>http://purl.org/dc/terms/extent</span> then 302-redirect
to a URL which, for administrative convenience, happens to contain a
release date, but which resolves to RDF which defines the unversioned
term <span class='url'>http://purl.org/dc/terms/extent</span>.  This
file includes the following content (translated into Turtle from the
original RDF/XML for legibility).</p>
<pre>@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix skos: &lt;http://www.w3.org/2004/02/skos/core#&gt; .
@prefix dcam: &lt;http://purl.org/dc/dcam/&gt; .
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .

&lt;http://purl.org/dc/terms/&gt;
  dcterms:title """DCMI Namespace for metadata terms
                in the http://purl.org/dc/terms/ namespace"""@en-us;
  rdfs:comment """To comment on this schema, 
               please contact dcmifb@dublincore.org.""";
  dcterms:publisher "The Dublin Core Metadata Initiative"@en-us;
  dcterms:modified "2008-01-14" .

dcterms:extent
  rdfs:label "Extent"@en-us;
  rdfs:comment "The size or duration of the resource."@en-us;
  rdfs:isDefinedBy &lt;http://purl.org/dc/terms/&gt;;
  dcterms:issued "2000-07-11";
  dcterms:modified "2008-01-14";
  a rdf:Property;
  dcterms:hasVersion &lt;http://dublincore.org/usage/terms/history/#extent-003&gt;;
  rdfs:range dcterms:SizeOrDuration;
  rdfs:subPropertyOf &lt;http://purl.org/dc/elements/1.1/format&gt;,
    dcterms:format .
...
</pre>
<p>This includes the definition of the (unversioned) <span class='url'
>http://purl.org/dc/terms/extent</span> concept, along with semantic
knowledge about the concept (<code>rdfs:subPropertyOf</code>) as of
2008-01-14, plus other editorial (<code>dcterms:modified</code>) and
definitional (<code>rdfs:isDefinedBy</code>) metadata.</p>

</div>

</div>

<div class='section' id='publishing'>
<p class='title'>Publishing vocabularies (normative)</p>

<div class='section' id='pubreq'>
<p class='title'>Requirements</p>

<p>A vocabulary which conforms to this IVOA standard has the following features.</p>

<div class='section' id='req-derefns'>
<p class='title'>Dereferenceable namespace</p>

<p>The namespace of the vocabulary <span class='rfc2119'>must</span>
be dereferenceable on the web.  That is, typing the namespace URL into
a web browser will produce human-readable documentation about the
vocabulary.  In addition, the namespace URL <span class='rfc2119'
>should</span> return an RDF version of the vocabulary if it is
retrieved with one of the RDF MIME types in the HTTP Accept header.
At the time of writing, the only fully standardised RDF MIME type is
<code>application/rdf+xml</code> for RDF/XML, but
<code>text/rdf+n3</code> and <code>text/turtle</code> are the proposed
types for Notation3 <span class='cite'>notation3</span> and Turtle
<span class='cite'>std:turtle</span>, respectively.</p>

<p><em>Rationale: These prescriptions are intended to be compatible
with the patterns described in <span class='cite'>berrueta08</span>
and <span class='cite'>sauermann08</span>, and vocabulary distributors
<span class='rfc2119' >should</span> follow these patterns where
possible.</em></p>
</div>

<div class='section' id='req-availability'>
<p class='title'>Long-term availability</p>


<p>The files defining a vocabulary, including those of superseded
versions, <span class='rfc2119' >should</span> remain permanently
available.  There is no requirement that the namespace URL be at any
particular location, although the IVOA web pages, or a journal
publisher's web pages, would likely be suitable archival
locations.</p> </div>

<div class='section' id='req-distformat'>
<p class='title'>Distribution format</p>

<p>Vocabularies <span class='rfc2119'>must</span> be made available
for distribution as SKOS RDF files in RDF/XML <span
class='cite'>std:rdfxml</span> format.  A human readable version in
Turtle <span class='cite'>std:turtle</span> format <span
class='rfc2119'>should</span> also be made available.  As an
alternative to Turtle, vocabularies may be made available in that
subset of Notation3 <span class='cite'>notation3</span> which is
compatible with Turtle; if Turtle or Notation3 is being served, it is
prudent to support both <code>text/rdf+n3</code> and
<code>text/turtle</code> as MIME types in the <code>Accept</code>
header of the HTTP request.  <!-- See issue <a
href='@ISSUESLIST@#distformat-2'>[distformat-2]</a> --></p>

<p>A publisher <span class='rfc2119'>may</span> make available RDF in
other formats, or other supporting files.  A publisher <span
class='rfc2119'>must</span> make available at least some
human-readable documentation – see section <span
class='xref'>servevocab</span> for a discussion of the mechanics here.</p>

<p><em>Rationale: this does imply that the vocabulary source files can only
realistically be parsed using an RDF parser.  An alternative is to
require that vocabularies be distributed using a subset of RDF/XML
which can also be naively handled as traditional XML; however as well
as creating an extra standardisation requirement, this would make it
effectively infeasible to write out the distribution version of the
vocabulary using an RDF or general SKOS tool.</em></p>
</div>

<div class='section' id='versioning'>
<p class='title'>Clearly versioned vocabulary</p>

<p>The vocabulary <em>namespace</em> <span class='rfc2119' >should
not</span> be versioned, but it <span class='rfc2119' >should</span>
be easy to retrieve earlier versions of the RDF describing the
vocabulary.  See the discussion in section <span
class='xref'>vocabversions</span> for the rationale for this, and see
section <span class='xref'>servevocab</span> for a discussion of its
implications for the way that vocabularies are served on the web.</p>

<!-- Issue <a href='@ISSUESLIST@#versioning-3' >[versioning-3]</a>-->

</div>

<div class='section' id='req-labels'>
<p class='title'>Concepts must have labels</p>

<p>Each concept <span class='rfc2119'>must</span> have both a URI
naming it, and a human-readable <code>skos:prefLabel</code> (the
first is a syntactic requirement of SKOS, and so is trivially
satisfied; the second is an extension to SKOS).</p>
</div>

<div class='section' id='req-sourcefiles'>
<p class='title'>No restrictions on source files</p>

<p>This Recommendation does not place any restrictions on the format of the
files managed by the maintenance process, as long as the distributed
files are as specified above.
<!-- See issue
<a href='@ISSUESLIST@#masterformat-1' >[masterformat-1]</a> -->
</p>
</div>

</div>

<div class='section' id='practices'>
<p class='title'>Good practices of vocabulary design</p>

<p>This standard imposes a number of requirements on conformant
vocabularies (see <span class='xref' >pubreq</span>).  In
this section we list a number of good practices that IVOA vocabularies
<span class='rfc2119'>should</span> abide by.  Some of the
prescriptions below are more specific than good-practice guidelines
for vocabularies in general.</p>

<p>The adoption of the following guidelines will make it easier to use
vocabularies in generic VO applications. However, VO applications
<span class='rfc2119'>must</span> be able to accept any vocabulary
that complies with the latest SKOS standard
<span class="cite">std:skosref</span> (this is a syntactical
requirement, and does not imply that an application will necessarily
understand the terms in
an alien vocabulary, although the presence of mappings to a known
vocabulary should allow it to derive some benefit).</p>

<ol>

<li><a name='practices-id'>SKOS concepts</a> are identified by strings which are, syntactically,
the fragment part of a URI.  As such, these identifiers must be
composed of characters from a restricted set.  The URI specification
<span class='cite'>std:rfc3986</span> permits a broad range of
characters in a URI fragment, but for simplicity, we recommend here
that concepts be identified by more restricted strings, and <span
class='rfc2119'>should</span> match the regular expression
<code>^[A-Za-z0-9][A-Za-z0-9._-]*$</code>.</li>

<li><a name='practices-readable'>For the sake</a> of expert users working directly with the concept
URIs, the concept identifiers <span class='rfc2119'>should</span> be
kept in human-readable form, directly reflecting the concept's
label, or place in a hierarchy, and not be semi-random identifiers
only (for example, use <code>spiralGalaxy</code>, not
<code>t1234567</code>).  [Rationale: When working with very large or
complicated vocabularies and ontologies, it is useful to have opaque
concept labels, to avoid confusion arising from the intuitive
semantics of a recognisable label.  This is less of a danger with the
simpler vocabularies we are discussing here, so we can safely retain the convenience of recognisable concept identifiers.]</li>

<li><a name='practices-labelnumber'>When developing</a> a <em>new</em>
vocabulary, standard thesaurus practice indicates that english
language labels for concrete concepts should be pluralised, though
abstract concepts remain singular – thus <code>"galaxies"@en</code>,
but <code>"astronomy"@en</code>.  Thesaurus practice in other
languages uses the singular for all cases.</li>

<li><a name='practices-existing'>However, when adapting</a> an existing
vocabulary into the SKOS format, implementors <span
class='rfc2119'>should not</span> change the labels (for example
changing the grammatical number) beyond any changes necessarily
required by SKOS.</li>

<li><a name='practices-conceptmd'>Each concept</a> <span class='rfc2119'>should</span> have a definition
(<code>skos:definition</code>) that constitutes a short description of
the concept which could be adopted by an application using the
vocabulary.  Each concept <span class='rfc2119'>should</span> have
additional documentation using SKOS Notes or
Dublin Core terms as appropriate
(see <span class='cite'>std:skosref</span>).  In practice, this
requirement is rather difficult to satisfy when converting pre-existing
structured vocabularies to SKOS, since these frequently provide
only labels, without fuller descriptions or scope notes; in this
case, vocabulary developers <span class='rfc2119'>should not</span>
add trivial descriptions which do little more than echo the label text.</li>

<li><a name='practices-lang'>The language localisation</a> <span class='rfc2119'>should</span> be
declared where appropriate, in preferred labels, alternate labels,
definitions, and the like.  Thus, use <code>"galaxies"@en</code>,
rather than just <code>"galaxies"</code>, even if there is only one
language being used in the vocabulary.</li>

<li><a name='practices-relations'>Relationships</a> (<q>broader</q>, <q>narrower</q>, <q>related</q>)
between concepts <span class='rfc2119'>should</span> be present, but
are not required; if used, they <span class='rfc2119'>should</span> be
complete (thus all <q>broader</q> links have corresponding
<q>narrower</q> links in the referenced entries and <q>related</q>
entries link each other).</li>

<li><a name='practices-topconcepts'>A vocabulary</a> <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. [Rationale: <q>top concepts</q> can be of
use as initial hints for a user interface which aims to help a user
navigate through a vocabulary starting from <q>the top</q>; if a
vocabulary is so flat that these <q>top concepts</q> would be too
numerous, then the vocabulary developer may reasonably decide not to
add them]</li>

<li><a name='practices-singlescheme'>A vocabulary</a>
<span class='rfc2119'>must</span> contain only one
<code>skos:ConceptScheme</code>.</li>

<li><a name='practices-csdoc'>The SKOS standard</a> describes some good
practices for vocabulary maintenance, such as using
<code>&lt;skos:changeNote&gt;</code> and the like, and these are
elaborated in the (currently draft) note <span
class='cite'>kendall08</span>.  At a minimum, the vocabulary's
<code>skos:ConceptScheme</code> <span class='rfc2119'>must</span> be
annotated with properties in the DC Terms namespace
<code>http://purl.org/dc/terms/</code>, namely <q>dc:title</q>,
<q>dc:creator</q>, <q>dc:created</q> and <q>dc:description</q>, with
values of an appropriate type, as illustrated above in <span
class='xref'>skos-format</span>.  Publishers <span
class='rfc2119'>should</span> respect such good practices as are
available to direct vocabulary development and maintenance.</li>

<li><a name='practices-mappings'>Publishers</a> <span class='rfc2119'>should</span> publish
<q>mappings</q> between their vocabularies and other commonly used
vocabularies (see <span class='xref'>distmappings</span>). These <span
class='rfc2119'>must</span> be external to
the defining vocabulary document so that the vocabulary can be used
independently of the publisher's mappings. The mapping file <span
class='rfc2119' >must</span> be annotated with DC terms <q>title</q>,
<q>creator</q>, <q>created</q> and <q>description</q>
<span class='cite'>std:dublincore</span>,
<span class='cite'>std:pubguide</span>.</li>



</ol>


<!--
<p>These suggestions are by no means trivial – there was
considerable discussion within the semantic working group on many of
these topics, particularly about token formats (some wanted lower-case
only), and singular versus plural forms of the labels (different
traditions exist within the international library science
community). Obviously, no publisher of an astronomical vocabulary has
to adopt these rules, but the adoption of these rules will make it
easier to use the vocabularly in external generic VO
applications. However, VO applications should be developed to accept
any vocabulary that complies with the latest SKOS standard <span
class="cite">std:skosref</span>.</p>
-->
</div>

<div class='section' id='servevocab'>
<p class='title'>Good practices when serving vocabularies on the web</p>

<p>The W3C Interest Group Note <em>Cool URIs for the Semantic Web</em>
<span class='cite'>sauermann08</span> presents guidelines for the
effective use of URIs when serving web documents and concepts on the
Semantic Web.  When providing vocabularies to the VO, we <span class='rfc2119'>recommend</span>
that publishers conform to these guidelines in general.  We make some
further observations below.</p>

<p>The “Cool URIs” guidelines describe a number of desirable
features of URIs in this context, namely simplicity, stability and
manageability.  Section 4.5 of the document describes
these features as follows (quoted directly).</p>
<dl>
<dt>Simplicity</dt>
<dd>Short, mnemonic URIs will not break as easily when sent in emails
and are in general easier to remember, e.g. when debugging your
Semantic Web server.</dd>
<dt>Stability</dt>
<dd>Once you set up a URI to identify a certain resource, it should
remain this way as long as possible. Think about the next ten
years. Maybe twenty. Keep implementation-specific bits and pieces such
as .php and .asp out of your URIs, you may want to change technologies
later.</dd>
<dt>Manageability</dt>
<dd>Issue your URIs in a way that you can manage. One good practice is
to include the current year in the URI path, so that you can change
the URI-schema each year without breaking older URIs. Keeping all 303
URIs on a dedicated subdomain,
e.g. <code>http://id.example.com/alice</code>, eases later migration
of the URI-handling subsystem.</dd>
</dl>
<p>We endorse this advice in this Recommendation: VO vocabularies
<span class='rfc2119'>should</span> use URIs which have these
properties.  The advice in the third point is a general point about
maintaining the general URI namespace on a particular server, and is
not about versioning vocabulary namespaces.</p>

<p>The “Cool URIs” document also describes two broad strategies for
making these URIs available on the web, which they name <em>303
URIs</em> and <em>hash URIs</em> (see the document, section 4, for
descriptions).  They note that the <em>hash URI</em> strategy <q>should
be preferred for rather small and stable sets of resources that evolve
together. The ideal case[s] are RDF Schema vocabularies and OWL
ontologies, where the terms are often used together, and the number of
terms is unlikely to grow out of control in the future.</q>  Since
this is the case for the (relatively small) SKOS vocabularies this
Recommendation discusses, and since an application will generally want
to use the complete vocabulary rather than only single concepts, we
suggest that vocabularies conformant to this Recommendation <span
class='rfc2119'>should</span> be distributed as <em>hash URI</em>
ones.</p>

<p>Common to the two strategies above is the insistence that the
vocabulary URIs <em>are HTTP URIs which are retrievable on the
web</em> – they differ only in the practicalities of achieving this.
The strategies also share the expectation that the vocabulary URIs are
retrievable both as RDF (machine-readable) and as HTML (providing
documentation for humans).  We elevate this to a requirement of this
Recommendation: vocabulary terms <span class='rfc2119'>must</span> be
HTTP URIs which <span class='rfc2119'>must</span> be dereferenceable
as both RDF and HTML using the mechanism appropriate to the URI naming
strategy.  Specifically, dereferencing the vocabulary namespace <span
class='rfc2119'>must</span> result in a 303 redirection to a URL which
produces a content type appropriate to the content type in any
<code>Accept</code> header in the initial request.</p>

</div>

<div class='section' id='recipe'>
<p class='title'>Example and recipe: serving the A&amp;A vocabulary (informative)</p>

<p>While <span class='cite'>sauermann08</span>, as quoted in section
<span class='xref'>servevocab</span>, discusses the design of
the URIs naming concepts, it says little about the mechanics of making
these available on the web.  We refer vocabulary publishers to the
recipe advice contained in <span class='cite'>berrueta08</span>, which
we illustrate here with an explicit recipe, in the case of the <em>hash URI</em> strategy.</p>

<p>The A&amp;A vocabulary has the namespace <span
class='url'>@BASEURI@/AAkeys</span> (see <span class='xref'>vocab-aa</span>).
In accordance with the above
guidelines, this namespace URI is dereferenceable, and if you enter
the URI into a web browser, you will end up at a page describing the
vocabulary.  The way this works can be illustrated by using
the <code>curl</code> utility to dereference the URI (URIs are cropped for legibility):</p>
<pre>% curl http://[...]/rdf/AAkeys
HTTP/1.1 303 See Other
Date: Thu, 08 May 2008 14:07:12 GMT
Server: Apache
Location: http://[...]/rdf/@DISTNAME@/AAkeys/AAkeys.html
Connection: close
Content-Type: text/html; charset=utf-8

&lt;title&gt;Redirected&lt;/title&gt;
&lt;p&gt;See &lt;a href='http://[...]/rdf/@DISTNAME@/AAkeys/AAkeys.html'
&gt;elsewhere&lt;/a&gt;&lt;/p&gt;
</pre>
<p>The server has responded to the HTTP GET for the URI with a 303
response, and a <code>Location</code> header, pointing to the HTML
representation of this thing.  In this example, the server has
included a brief HTML explanation in case a human happens to see this response.</p>

<p>If we instead request an RDF representation, by stating a desired
MIME type in the HTTP <code>Accept</code> header, we get a slightly
different response:</p>
<pre>% curl --head -H accept:text/turtle http://[...]/rdf/AAkeys
HTTP/1.1 303 See Other
Date: Thu, 08 May 2008 14:11:28 GMT
Server: Apache
Location: http://[...]/rdf/@DISTNAME@/AAkeys/AAkeys.ttl
Connection: close
Content-Type: text/html; charset=iso-8859-1
</pre>
<p>This is also a 303 response, but the <code>Location</code> header
this time points to an RDF file in Turtle syntax, which we can now retrieve normally.</p>
<pre>% curl --include http://[...]/rdf/@DISTNAME@/AAkeys/AAkeys.ttl
HTTP/1.1 200 OK
Date: Thu, 08 May 2008 14:13:35 GMT
Server: Apache
Content-Type: text/turtle; charset=utf-8

@base &lt;http://[...]/rdf/AAkeys&gt; .
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix dc: &lt;http://purl.org/dc/terms/&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
@prefix : &lt;http://www.w3.org/2004/02/skos/core#&gt; .

&lt;&gt;
  dc:created "2008-05-08" ;
  dc:title "Vocabulary for Astronomy &amp; Astrophysics Journal keywords (Version wd-1.0)"@en ;
  dc:creator [
    foaf:name "The IVOA Semantics Working Group" 
  ];
   dc:description "This is a list of journal keywords developed by ...";
  a :ConceptScheme ;
# and so on...
</pre>
<p>Note that the base URI in the returned RDF still refers to the
unversioned concept names.</p>

<p>This behaviour is controlled by (in this case) an Apache
<code>.htaccess</code> file which looks like this:</p>
<pre>AddType application/rdf+xml .rdf
# The MIME type for .n3 should be text/rdf+n3, not application/n3:
# see MIME notes at &lt;http://www.w3.org/2000/10/swap/doc/changes.html&gt;
#
# The MIME type for Turtle is text/turtle, though this has not
# completed its registration: see
# &lt;http://www.w3.org/TeamSubmission/turtle/#sec-mediaReg&gt;
AddType text/rdf+n3 .n3
AddType text/turtle .ttl
# For Charset types, see &lt;http://www.iana.org/assignments/character-sets&gt;
AddCharset UTF-8 .n3
AddCharset UTF-8 .ttl

RewriteEngine On
# This will match the directory where this file is located.
RewriteBase /users/norman/ivoa/vocabularies/rdf

RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ @DISTNAME@/$1/$1.rdf [R=303]

RewriteCond %{HTTP_ACCEPT} text/rdf\+n3 [OR]
RewriteCond %{HTTP_ACCEPT} application/n3 [OR]
RewriteCond %{HTTP_ACCEPT} text/turtle
RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ @DISTNAME@/$1/$1.ttl [R=303]

# Any other accept header, including none: make the .html version the default
RewriteRule ^(AAkeys|AVM|UCD|IVOAT|IAUT93)$ @DISTNAME@/$1/$1.html [R=303]
</pre>
<p>These various <code>RewriteRule</code> statements examine the
content of the HTTP <code>Accept</code> header, and return
303-redirections to the appropriate actual resource.</p>

<p>Note that the namespace remains unversioned throughout the
maintenance history of this vocabulary, even though the actual RDF
files being returned might change as labels or relationships are
adjusted.  Previous versions of the vocabulary RDF will remain
available, though they will no longer be served by dereferencing the
namespace URL.</p>

</div>


</div> 


<div class="section" id='distvocab'>
<p class="title">SKOS versions of existing vocabularies (normative)</p>

<p>The intent of having the IVOA adopt SKOS as the preferred format
for astronomical vocabularies is to encourage the creation and
management of diverse vocabularies by competent astronomical groups,
so that users of the VO and related resources can benefit directly and
dynamically without the intervention of the IAU or IVOA.  In this
section, we include SKOS versions of several vocabularies which
already exist, and have some usage within astronomy.  This illustrates
the use of SKOS with real vocabularies, but also, more importantly,
makes these vocabularies available for immediate use in VO
applications.</p>

<p>The vocabularies described below are included, as SKOS files, in
the distributed version of this standard.  These vocabularies have
stable URLs, and may be cited and used indefinitely.  These
vocabularies will not, however, be developed as part of the
maintenance of this standard.  Interested groups, within and outwith
the IVOA, are encouraged to take these as a starting point and absorb
them within existing processes.</p>

<p>The exceptions to this rule are the constellation vocabulary,
provided here mainly for didactic purposes, and the proposed IVOA
Thesaurus, which is being developed as a separate project and whose
aim is to provide a corrected, more user-friendly, more complete, and
updated version of the 1993 IAU thesaurus.  Although work on the IVOA
Thesaurus is on-going, the fact that it is largely based on the IAU
thesaurus means that it is already a very useful resource, so a usable
snapshot of this vocabulary will be published with the other
examples.</p>

<p>We provide a set of SKOS files representing the vocabularies which
have been developed, and an example mapping file between the A&amp;A
keywords and the AVM Taxonomy.  These vocabularies
have base URIs starting <span class='url'>@BASEURI@</span>, and can be
downloaded at the URL</p>
<blockquote>
<span class='url'>@BASEURI@/@DISTNAME@.tar.gz</span>
</blockquote>

<div class='section' id='vocab-constellation'>
<p class='title'>A Constellation Name Vocabulary (informative)</p>

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

<p>The <code>&lt;skos:ConceptScheme&gt;</code> contains a single
<code>&lt;skos:TopConcept&gt;</code>, <q>constellation</q></p>

<center>
<table>
<tr><th bgcolor="#eecccc">XML Syntax</th>
  <th width="10"/><th bgcolor="#cceecc">Turtle Syntax</th></tr>
<tr><td/></tr>
<tr>
<td class='rdfxml'>
<pre class='rdfxml'>&lt;skos:Concept rdf:about="#constellation"&gt;
  &lt;skos:inScheme rdf:resource=""/&gt;
  &lt;skos:prefLabel&gt;
    constellation
  &lt;/skos:prefLabel&gt;
  &lt;skos:definition&gt;
    IAU-sanctioned constellation names
  &lt;/skos:definition&gt;
  &lt;skos:narrower rdf:resource="#Andromeda"/&gt;
  ...
  &lt;skos:narrower rdf:resource="#Vulpecula"/&gt;
&lt;/skos:Concept&gt;
</pre>
</td>
<td/>
<td class='turtle'>
<pre class='turtle'>&lt;#constellation&gt; a :Concept;
  :inScheme &lt;&gt;;
  :prefLabel "constellation";
  :definition "IAU-sanctioned constellation names";
  :narrower &lt;#Andromeda&gt;;
  ...
  :narrower &lt;#Vulpecula&gt;.
</pre>
</td></tr>
</table></center>
<p>and the entry for <q>Cygnus</q> is</p>
<center><table><tr>
<td class='rdfxml'>
<pre class='rdfxml'>&lt;skos:Concept rdf:about="#Cygnus"&gt;
  &lt;skos:inScheme rdf:resource=""/&gt;
  &lt;skos:prefLabel&gt;Cygnus&lt;/skos:prefLabel&gt;
  &lt;skos:definition&gt;Cygnus&lt;/skos:definition&gt;
  &lt;skos:altLabel&gt;Cygni&lt;/skos:altLabel&gt;
  &lt;skos:altLabel&gt;Cyg&lt;/skos:altLabel&gt;
  &lt;skos:broader rdf:resource="#constellation"/&gt;
  &lt;skos:scopeNote&gt;
    Cygnus is nominative form; the alternative
    labels are the genitive and short forms
  &lt;/skos:scopeNote&gt;
&lt;/skos:Concept&gt;
</pre>
</td>
<td width="10"/>
<td class='turtle'>
<pre class='turtle'>&lt;#Cygnus&gt; a :Concept;
  :inScheme &lt;&gt;;
  :prefLabel "Cygnus";
  :definition "Cygnus";
  :altLabel "Cygni";
  :altLabel "Cyg";
  :broader &lt;#constellation&gt;;
  :scopeNote """Cygnus is nominative form;
    the alternative labels are the genitive and
    short forms""" .
</pre>
</td>
</tr></table></center>

<p>Note that SKOS alone does not permit the distinct differentiation
of genitive forms and abbreviations, but the use of alternate labels
is more than adequate enough for processing by VO applications where
the difference between <q>SS Cygni</q>, <q>SS Cyg</q>, and the incorrect form
<q>SS Cygnus</q> is probably irrelevant.</p>
</div>

<div class='section' id='vocab-aa'>
<p class='title'>The Astronomy &amp; Astrophysics Keyword List</p>

<p>Namespace: <span class='url'>@BASEURI@/AAkeys</span>.</p>

<p>This vocabulary is based on a set of keywords maintained jointly by the
publishers of the journals <em>Astronomy and Astrophysics</em>
(A&amp;A), <em>Monthly Notices of the Royal Astronomical Society</em>
(MNRAS) and the <em>Astrophysical Journal</em> (ApJ), and updated on
an annual basis.  As noted in the
introduction, an analysis of these keywords <span
class='cite'>preitemartinez07</span> indicates that the different
journals are slightly inconsistent with each other; we have rather
arbitrarily used the 2008 list from the A&amp;A web site.  The intended
usage of the vocabulary is to tag articles with descriptive keywords
to aid searching for articles on a particular topic.</p>

<p>The keywords are organised into categories which have been modelled as
hierarchical relationships.
Additionally, some of the keywords are grouped into collections which
has been mirrored in the SKOS version.
The vocabulary contains no definitions or related links as these are
not provided in the original keyword list, and only a handful of
alternative labels and scope notes that are present in the original
keyword list.</p>

</div>

<div class='section' id='vocab-avm'>
<p class='title'>The AVM Taxonomy</p>

<p>Namespace: <span class='url'>@BASEURI@/AVM</span>.</p>

<p>This vocabulary is published by the <em>Virtual Astronomy
Multimedia Project</em> (<span
class='url'>http://www.virtualastronomy.org/</span> and <span
class='cite'>std:avm</span>) to allow images to be
tagged with keywords that are relevant for the public.  It consists of
a set of keywords organised into an enumerated hierarchical structure.
Each term consists of a taxonomic number and a label.  There are no
definitions, scope notes, or cross references.</p>

<p>When converting the AVM into SKOS, The IVOA working group decided to model the
taxonomic number as both a <code>skos:notation</code> and an alternative 
label. Since some terms are duplicated, the token for a term consists of
the taxonomical number to avoid ambiguity and to keep the tokens short.
<!--
the full hierarchical location of the term.
Thus, it is possible to distinguish between</p>
<pre>Planet -> Feature -> Surface -> Canyon</pre>
<p>and</p>
<pre>Planet -> Satellite -> Feature -> Surface -> Canyon</pre>
<p>which have the tokens <code>PlanetFeatureSurfaceCanyon</code> and
<code>PlanetSatelliteFeatureSurfaceCanyon</code> respectively.-->
</p>

</div>

<div class='section' id='vocab-ucd1'>
<p class='title'>The UCD1+ Vocabulary</p>

<p>Namespace: <span class='url'>@BASEURI@/UCD</span>.</p>

<p>The UCD standard is an officially sanctioned and managed vocabulary
of the IVOA <span class='cite'>std:ucd</span>. The normative document is a simple text file containing
entries consisting of tokens (for example <code>em.IR</code>), a short
description, and usage information (<q>syntax codes</q> which permit
UCD tokens to be concatenated). The form of the tokens implies a
natural hierarchy: <code>em.IR.8-15um</code> is obviously a narrower
term than <code>em.IR</code>, which in turn is narrower than
<code>em</code>.</p>

<p>Given the structure of the UCD1+ vocabulary, the natural
translation to SKOS consists of preferred labels equal to the original
tokens (the UCD1 words include dashes and periods), vocabulary tokens
created using guidelines in <span class='xref'
>practices</span> (for example, "emIR815Um" for
<code>em.IR.8-15um</code>), direct use of the definitions, and the syntax codes
placed in usage documentation: <code>&lt;skos:scopeNote&gt;UCD syntax code: P&lt;/skos:scopeNote&gt;</code></p>


<p>Note that the SKOS document containing the UCD1+ vocabulary does
NOT consistute the official version: the normative document is still
the text list. However, on the long term, the IVOA may decide to make
the SKOS version normative, since the SKOS version contains all of the
information contained in the original text document but has the
advantage of being in a standard format easily read and used by any
application on the semantic web whilst still being usable in the
current ways.</p>

</div>

<div class='section' id='vocab-iau93'>
<p class='title'>The 1993 IAU Thesaurus</p>

<p>Namespace: <span class='url'>@BASEURI@/IAUT93</span>.</p>

<p>The IAU Thesaurus consists of concepts with mostly capitalised
labels and a rich set of thesaurus relationships (<q>BT</q> for
"broader term", <q>NT</q> for <q>narrower term</q>, and <q>RT</q> for
<q>related term</q>).  The thesaurus also contains <q>U</q> (for
<q>use</q>) and <q>UF</q> (<q>use for</q>) relationships.  In a SKOS
model of a vocabulary these are captured as alternative labels.  A
separate document contains translations of the vocabulary terms in
five languages: English, French, German, Italian, and
Spanish.  Enumerable concepts are plural (for example <q>SPIRAL
GALAXIES</q>) and non-enumerable concepts are singular
(for example <q>STABILITY</q>). Finally, there are some usage hints like
<q>combine with other</q>, which have been modelled as scope notes.</p>

<p>In converting the IAU Thesaurus to SKOS, we have been as faithful
as possible to the original format of the thesaurus. Thus, preferred
labels have been kept in their uppercase format.</p>

<p>The IAU Thesaurus has been unmaintained since its initial production in
1993; it is therefore significantly out of date in places.  This
vocabulary is published for the sake of completeness, and to make the
link between the evolving vocabulary work and any uses of the 1993
vocabulary which come to light.  We do not expect to make any future
maintenance changes to this vocabulary, and would expect the IVOAT
vocabulary, based on this one, to be used instead (see <span class='xref'>vocab-ivoat</span>).</p>

</div>

<div class='section' id='vocab-ivoat'>
<p class='title'>Towards an IVOA Thesaurus (informative)</p>

<p>While it is true that the adoption of SKOS will make it easy to
publish and access different astronomical vocabularies, the fact is
that there is no vocabulary which makes it easy to jump-start the
use of vocabularies in generic astrophysical VO applications: each of
the previously developed vocabularies has their own limits and
biases. For example, the IAU Thesaurus provides a large number of
entries, copious relationships, and translations to four other languages,
but there are no definitions, many concepts are now only useful for
historical purposes (for example many photographic or historical instrument
entries), some of the relationships are false or outdated, and many
important or newer concepts and their common abbreviations are
missing.</p>

<p>Despite its faults, the IAU Thesaurus constitutes a very extensive
vocabulary which could easily serve as the basis vocabulary once
we have removed its most egregious faults and extended it to cover the
most obvious semantic holes. To this end, a heavily revised IAU
thesaurus is in preparation for use within the IVOA and other
astronomical contexts. The goal is to provide a general vocabulary
foundation to which other, more specialised, vocabularies can be added
as needed, and to provide a good <q>lingua franca</q> for the creation of
vocabulary mappings.</p>
</div>
</div> <!-- End: Example vocabularies -->

<div class='section' id='distmappings'>
<p class='title'>Mapping vocabularies (informative)</p>

<p>Part of the motivation for formalising vocabularies within the VO
is to support <em>mapping between vocabularies</em>, so that an
application which understands, or can natively process, one
vocabulary, can use a mapping to provide at least partial support for
data described using another vocabulary.
Section 10 of the SKOS standard <span class='cite'>std:skosref</span> describes
a number of properties for expressing such matches, and we anticipate
that we will shortly see explicit mappings between vocabularies,
produced either by vocabulary maintainers, describing the
relationships between their own vocabularies and others, or by third
parties, asserting such relationships as an intellectual contribution
of their own.</p>

<p>The vocabularies distributed in association with this document
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>

<p>Mapping: <span class='url'>@BASEURI@/AAkeys2AVMMapping</span>.</p>

<!--
<p>To show how mappings can be expressed between two vocabularies, we
have provided one example mapping document which maps the concepts in
the A&amp;A Keywords vocabulary to the concepts in the AVM
vocabulary.
All four types of mappings were required.
Since all the mapping relationships have inverse relationships
defined, the mapping document can also be used to infer the set of
mappings from the AVM vocabulary to the A&amp;A keywords.</p>

<p>To provide provenence information about the set of mappings in a
document, Dublin Core metadata is included in the mapping
document.</p>

-->

</div>

<div class="appendices">

<div class="section-nonum" id="bibliography">
<p class="title">References</p>
<?bibliography rm-refs ?>
</div>

<p style="text-align: right; font-size: x-small; color: #888;">
$Revision$ $Date$
</p>

</div>

</body>
</html>

Show details Hide details

Change log

r1097 by norman.x.gray on Jun 22, 2009 Diff

Validator tweaks; fixing vocabularies to
conform to prescriptions
Release this as another 'editors draft'

Go to:

Project members, sign in to write a code review

Older revisions

r1076 by norman.x.gray on Jun 05, 2009 Diff

Revert SKOS namespace to
http://www.w3.org/2004/02/skos/core#

r970 by norman.x.gray on Mar 24, 2009 Diff

Clarify scope, after correspondence
with community; some minor language
fixes

r940 by norman.x.gray on Feb 24, 2009 Diff

Clarify the required and optional
features
Addresses  issue 12

All revisions of this file

File info

Size: 80497 bytes, 1791 lines

View raw file

File properties

svn:keywords: Author Date Revision