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 name="rcsdate" content="$Date$"/>
<link href="http://www.ivoa.net/misc/ivoa_wd.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; }
span.userinput { font-weight: bold; }
span.url { font-family: monospace; }
span.rfc2119 { color: #800; }
q { color: #666; }
q:before { content: "“"; }
q:after  { content: "”"; }
.todo { background: #ff7; }

/* 'link here' text in section headers */
*.hlink a {
  text-decoration: none;
  color: #fff; /* the page background colour */
}
*:hover.hlink a {
  color: #800;
}
</style>
</head>

<body>
<div class="head">
<table>
<tr><td><a href="http://www.ivoa.net/"><img alt="IVOA logo" src="http://ivoa.net/icons/ivoa_logo_small.jpg" border="0"/></a></td></tr>
</table>

<h1>Vocabularies in the Virtual Observatory, v@VERSION@</h1>
<h2>IVOA Working Draft, @RELEASEDATE@ [DRAFT $Revision$]</h2>
<!-- $Revision$ $Date$ -->

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

<dt>This version</dt>
<dd><span class='url'>http://www.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics</span><br/>
<span class='url'>@BASEURI@.xhtml</span></dd>

<dt>Latest version</dt>
<dd><span class='url'>@DISTURI@</span><br/>
and <a href='@DISTURI@/issues' >issues list</a></dd>

<dt>Editors</dt>
<dd>Alasdair J G Gray,
<a href='http://nxg.me.uk/norman#norman' >Norman Gray</a>,
Frederic V Hessman and
Andrea Preite Martinez</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>As the astronomical information processed within the <em>Virtual Observatory
</em> becomes more complex, there is an increasing need for a more
formal means of identifying quantities, concepts, and processes not
confined to things easily placed in a FITS image, or expressed in a
catalogue or a table.  We proposed that the IVOA adopt a standard
format for vocabularies based on the W3C's <em>Resource Description
Framework</em> (RDF) and <em>Simple Knowledge Organisation 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 combined them.  The use of current, open standards
ensures that VO applications will be able to tap into resources of the
growing semantic web.  Several examples of useful astronomical
vocabularies are provided, including work on a common IVOA thesaurus
intended to provide a semantic common base for VO applications.</p>
</div>

</div>

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

<p>This is (<strong>an internal draft of</strong>) an IVOA Working
Draft.  The first release of this document was
<span property="dc:date">@RELEASEDATE@</span>.</p>

<p>This document is an IVOA Working Draft for review by IVOA members
and other interested parties.  It is a draft document and may be
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use IVOA Working Drafts as reference materials or to
cite them as other than <q>work in progress</q>.</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>

<h3>Acknowledgments</h3>

<p>We would like to thank the members of the IVOA semantic working
group for many interesting ideas and fruitful discussions.</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">
<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 a number of basic forms of organised semantic knowledge
of potential use to the VO, ranging from informal <q>folksonomies</q>
(where users are free to choose their own labels) at one extreme, to
formally structured <q>vocabularies</q> (where the label is drawn from
a predefined set of definitions, and which can include relationships between
labels) and <q>ontologies</q> (where the domain is captured in a
formal data model) at the other.
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) `understand' 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, 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 `about', 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 <span
class="todo">[TODO] Check differences from the A&amp;A
list</span>.</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:aoim</span>.  See
<span class='xref'>vocab-aoim</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' >shobbrook92</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 `burst' 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
area sometimes referred to as `folksonomies'), but the astronomical
community, with a culture sympathetic to international agreement, can
do better.</p>

<p>The purpose of this proposal is to establish 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 proposal
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 her to narrow her search using one of a set of terms
including, say, binary lens events. [This supports so-called `semantic
search', 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 is 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 AOIM 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>

</ul>

<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 – such 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 <span class='xref'>distvocab</span> are directly derived from
existing vocabularies, with adjustments to make them structurally
compatible with SKOS, or to remove (in the case of the IAU-93 and
IVOAT pair) significant anachronisms.  It therefore follows that the
ambiguities, redundancies and incompleteness of the source vocabularies
are faithfully represented in the distributed SKOS vocabularies.</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 widely enough
deployed to be useful.</p>

</div>

<div class="section">
<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'>
<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
Organisation 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 community, 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.</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
thesaurus as a</p>
<blockquote>
Controlled vocabulary in which concepts are represented by preferred
terms, formally organized 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 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.</p>

<p>Thus <strong>a vocabulary (SKOS or otherwise) is not an
ontology</strong>.  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'>
<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 N3 notation).  The elements of a concept are detailed
below.</p>

<center>
<p><a name='figexample' >Figure: examples of SKOS vocabularies</a></p>
<table>
<tr>
<th bgcolor="#eecccc">XML Syntax</th>
<th width="10"/>
<th bgcolor="#cceecc">Turtle Syntax</th>
</tr>
<tr><td/></tr>
<tr> 
<td bgcolor="#eecccc">
  <pre>
&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: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 galaxy having a spiral structure.
  &lt;/skos:definition&gt;
  &lt;skos:scopeNote lang="en"&gt;
    Spiral galaxies fall into one of 
    three catagories: Sa, Sc, and Sd.
  &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;
</pre>
</td>
<td/> 
<td bgcolor="#cceecc">
<pre>
&lt;#spiralGalaxy&gt; a skos:Concept;
  skos:prefLabel
    "spiral galaxy"@en, 
    "Spiralgalaxie"@de;
  skos:altLabel "spiral nebula"@en;
  skos:hiddenLabel "spiral glaxy"@en;
  skos:definition """A galaxy having a 
    spiral structure."""@en;
  skos:scopeNote """Spiral galaxies fall
    into one of three categories:
    Sa, Sc, and Sd"""@en;
  skos:narrower &lt;#barredSpiralGalaxy&gt;;
  skos:broader &lt;#galaxy&gt;;
  skos:related &lt;#spiralArm&gt; .
</pre>
</td>
</tr> 
</table>
</center> 

<p>A SKOS vocabulary includes the following features.</p>

<ul> 

<li>A single URI representing the concept, mainly for use by computers.
<!--
<code>&lt;#spiralGalaxy&gt; a skos:Concept</code>.
<code>&lt;skos:Concept rdf:about="#spiralGalaxy"&gt;</code>
--> 
</li>

<li>A single prefered label in each supported language of the
vocabulary, for use by humans.
<!-- 
<code>skos:prefLabel "spiral galaxy"@en, "Spiralgalaxie"@de</code>.
<code>&lt;skos:prefLabel&gt;spiral galaxy&lt;/skos:prefLabel&gt;</code>
-->
</li>

<li>Optional alternative labels which applications may encounter or in
common use, whether simple synonyms or commonly-used aliases,
e.g. <q>GRB</q> for "gamma-ray burst", or <q>Spiral nebula</q> for
spiral galaxies.
<!-- 
<code>skos:altLabel "GRB"@en</code> 
<code>&lt;skos:altLabel lang="de"&gt;Spiralgalaxie&lt;/skos:altLabel&gt;</code>
-->
</li>

<li>Optional hidden labels which capture terms which are sometimes
used for the corresponding concept, but which are deprecated in some
sense.  This might include common misspellings for
either the preferred or alternate labels, for example <q>glaxy</q> for
<q>galaxy</q>.
</li>

<li>A definition for the concept, where one exists in the original
vocabulary, to clarify the meaning of the term.
<!--
<code>skos:definition "A galaxy having a spiral structure."@en</code>
<code>&lt;skos:definition lang="en"&gt;<br/>A galaxy having a spiral structure.<br/>&lt;/skos:definition&gt;</code>
-->
</li>

<li>A scope note to further clarify a definition, or the usage of the
concept.
<!-- 
<code>skos:scopeNote "Spiral galaxies fall into one of three categories: Sa, Sc, and Sd"@en</code>
<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>
-->
</li>

<li>Optionally, a concept may be involved in any number of relationships
to 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>.
<!--
<code>skos:narrower &lt;#barredSpiralGalaxy&gt;</code>.
<code>&lt;skos:narrower rdf:resource="#barredSpiralGalaxy"&gt;</code> 
-->
</li>
<li>Broader or more general concepts, for example a link to the token
representing galaxies in general. 
<!-- 
<code>skos:broader &lt;#galaxy&gt;</code>.
<code>&lt;skos:broader rdf:resource="#galaxy"&gt;</code>
-->
</li>
<li>Related concepts, for example a link to the token representing spiral
arms of galaxies
<!-- 
<code>skos:related &lt;#spiralArm&gt;</code>
<code>&lt;skos:related rdf:resource="#spiralArm"&gt;</code> 
-->
<br/>
(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>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, e.g. the publisher, may
be documented using the Dublin Core metadata set <span class='cite'
>std:dublincore</span>.</li>
</ul>
</div>


<div class='section'>
<p class='title'>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 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:
</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 aoim:#Cosmology</code>
</blockquote>
which states that the cosmology concept in the A&amp;A Keywords is the
same as the cosmology concept in the AOIM.
(Note the use of an external namespaces <code>AAkeys</code> and
<code>aoim</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 aoim:PlanetSatellite</code>
</blockquote>
which states that the AOIM concept Planet Satellite is a more general
term than the A&amp;A Keywords concept Moon.
</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 
  aoim:#NebulaAppearanceDarkMolecularCloud</code>
</blockquote>
which states that the AOIM concept Nebula Appearance Dark Molecular
Cloud is more specific than the A&amp;A Keywords concept ISM Clouds.  
</li>

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

</ul>

<p>
<!-- <span class='todo'>[TODO:] Enter text regarding the resolution of <a
href="http://code.google.com/p/volute/issues/detail?id=7">Issue
7</a>.</span> -->

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>

</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.  In this section, the keywords 
<span class='rfc2119' >must</span>,
<span class='rfc2119' >should</span>
and so on, are to be interpreted as described in <span
class='cite'>std:rfc2119</span>.</p>

<div class='section'>
<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 the RDF version of the vocabulary if it is retrieved with an
HTTP Accept header of <code>application/rdf+xml</code>.</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'>sauermann07</span>, and vocabulary distributors
<span class='rfc2119' >should</span> follow these patterns where
possible.</em></p>
</div>

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

<p>The files defining a
vocabulary, including those of superseded versions, should remain
permanently available.  There is no requirement that the namespace
URL be at any particular location, although the IVOA web pages, or the
online sections of the A&amp;A journal would likely be suitable
archival locations.</p>
</div>

<div class='section'>
<p class='title'>Distribution format</p>

<p>Vocabularies <span class='rfc2119'>must</span> be made available
for distribution as SKOS RDF files, in either RDF/XML <span
class='cite'>std:rdfxml</span> or Turtle <span
class='cite'>std:turtle</span> format; vocabularies <span
class='rfc2119'>should</span> be made available in both formats.  See
issue <a href='@DISTURI@/issues#distformat-2'>[distformat-2]</a>.</p>

<p>A publisher <span class='rfc2119'>may</span> make available
documentation and supporting files in other formats.</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'>
<p class='title'>Clearly versioned vocabulary</p>

<p><span class='todo' >To be decided.  There are interactions with
'long-term availability' and 'dereferenceable namespace', since this
implies that the vocabulary version should be manifestly encoded in
the namespace URI.</span> See issue <a
href='@DISTURI@/issues#versioning-3' >[versioning-3]</a>.</p>

</div>

<div class='section'>
<p class='title'>No restrictions on source files</p>

<p>This standard 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='@DISTURI@/issues#masterformat-1' >[masterformat-1]</a>.</p>
</div>

</div>

<div class='section' id='practices'>
<p class='title'>Suggested good practices</p>

<p>This standard imposes a number of requirements on conformant
vocabularies (see <span class='xref' >publishing</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'>should</span> be able to accept any vocabulary
that complies with the latest SKOS standard
<span class="cite">std:skosref</span> (this does not imply, of
course, 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>Concept identifiers <span class='rfc2119'>should</span> consist
only of the letters a-z, A-Z, and numbers 0-9, i.e. no spaces, no
exotic letters (e.g. umlauts), and no characters which would make a
token inexpressible as part of a URI; since tokens are for use by
computers only, this is not a big restriction, since the exotic
letters can be used within the labels and documentation if
appropriate.</li>

<li>The concept identifiers <span class='rfc2119'>should</span> be
kept in human-readable form, directly reflect the implied meaning, and
not be semi-random identifiers only (for example, use
<q>spiralGalaxy</q>, not "t1234567"); tokens <span
class='rfc2119'>should</span> preferably be created via a direct
conversion from the preferred label via removable/translation of
non-token characters (see above) and sub-token separation via
capitalisation of the first sub-token character (e.g. the label "My
favourite idea-label #42" is converted into
"MyFavouriteIdeaLabel42").</li>

<li>Labels <span class='rfc2119'>should</span> be in the form of the source vocabulary. When
developing a new vocabulary the singular form <span
class='rfc2119'>should</span> be preferred,
e.g. <q>spiral galaxy</q>, not "spiral galaxies". <span
class='todo'><a
href="http://code.google.com/p/volute/issues/detail?id=1">Open
issue</a></span></li>

<li>Each concept <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>)</li>

<li>The language localisation <span class='rfc2119'>should</span> be
declared where appropriate, in preferred labels, alternate labels,
definitions, and the like.</li>

<li>Relationships (<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><q>TopConcept</q> entries (see above) <span
class='rfc2119'>should</span> be declared and normally consist of
those concepts that do not have any <q>broader</q> relationships
(i.e. not at a sub-ordinate position in the hierarchy).</li>

<li>The SKOS standard describes some good practices for vocabulary
maintenance, such as using <code>&lt;skos:changeNote&gt;</code> and
the like.  Publishers <span class='rfc2119'>should</span> respect such
good maintenance practices are are available.</li>

<li>Publishers <span class='rfc2119'>should</span> publish
<q>mappings</q> between their vocabularies and other commonly used
vocabularies. These <span class='rfc2119'>should</span> be external to
the defining vocabulary document so that the vocabulary can be used
independently of the publisher's mappings.  <span class='todo' ><a
href='http://code.google.com/p/volute/issues/detail?id=8' >Open
issue</a></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> 


<div class="section" id='distvocab'>
<p class="title">Example vocabularies</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. However, we
felt it important to provide several examples of vocabularies in the
SKOS format as part of the proposal, to illustrate their simplicity
and power, and to provide an immediate vocabulary basis for 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 <span class='todo' >Format TBD, see
<a href='@DISTURI@/issues#versioning-3' >[versioning-3]</a></span>, 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 an existing
process.</p>

<p>The exception to this is the IVOA-T (see <span class='xref'
>vocab-ivoat</span>), which will be developed as part of a process
which has already begun.  <span class='todo' >Clarify wording here;
include reference to forthcoming IVOA-T document; ??include snapshot
of vocabulary in the distribution??</span>.</p>

<p>We provide a set of SKOS files representing the vocabularies which
have been developed, and mappings between them.  These can be
downloaded at the URL</p>
<blockquote>
<span class='url'>@BASEURI@/@DISTNAME@.tar.gz</span>
</blockquote>
<p class='todo'>Not yet: instead go to
<span class='url'>http://code.google.com/p/volute/downloads/list</span></p>

<p><span class='todo' >[To be expanded:] there are no mappings at the
moment.  Also, the vocabularies are all in a single language, though
translations of the IAU93 thesaurus are available.  See also
issue <a href='@DISTURI@/issues#mappings-6'>[mappings-6]</a>.</span></p>

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

<p>This vocabulary is presented as a simple example of an astronomical vocabulary for a very particular purpose, e.g. 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 &lt;skos:ConceptScheme&gt; contains a single &lt;skos:TopConcept&gt;, <q>constellation</q></p>
<br/><br/><center>
<table>
<tr><th bgcolor="#eecccc">XML Syntax</th>
  <th width="10"/><th bgcolor="#cceecc">Turtle Syntax</th></tr>
<tr><td/></tr>
<tr>
<td bgcolor="#eecccc">
<pre>
&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 bgcolor="#cceecc">
<pre>
&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 bgcolor="#eecccc">
<pre>
&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 bgcolor="#cceecc">
<pre>
&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>
This vocabulary is a set of keywords made available on a web page by
the publisher of the journal.
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-aoim'>
<p class='title'>The AOIM Taxonomy</p>

<p>
This vocabulary is published by the IVOA 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 AOIM into SKOS, it was decided to model the
taxonomic number as an alternative label.
Since there are duplication of terms, the token for a term consists of
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>The UCD standard is an officially sanctioned and managed vocabulary
of the IVOA. The normative document is a simple text file containing
entries consisting of tokens (e.g. <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> (e.g., "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>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 (e.g. <q>SPIRAL
GALAXIES</q>) and non-enumerable concepts are singular
(e.g. <q>STABILITY</q>). Finally, there are some usage hints like
<q>combine with other</q></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</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 (e.g. 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'>Example Mapping</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 AOIM
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 AOIM 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>

<p><span class='todo'>To come</span></p>

</div>

<div class="appendices">

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

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

</div>

</body>
</html>
msdemlei@ari.uni-heidelberg.de	ViewVC Help
Powered by ViewVC 1.1.26