| 1 |
<html xmlns="http://www.w3.org/1999/xhtml" |
| 2 |
xmlns:dc="http://purl.org/dc/elements/1.1/" |
| 3 |
xmlns:dcterms="http://purl.org/dc/terms/" |
| 4 |
xmlns:grddl="http://www.w3.org/2003/g/data-view#" |
| 5 |
grddl:transformation="http://ns.inria.fr/grddl/rdfa/2007/05/25/RDFa2RDFXML.xsl" |
| 6 |
> |
| 7 |
|
| 8 |
<head> |
| 9 |
<link href="http://www.ivoa.net/misc/ivoa_note.css" |
| 10 |
rel="stylesheet" |
| 11 |
type="text/css"/> |
| 12 |
<title>Issues list: Vocabularies in the Virtual Observatory</title> |
| 13 |
<meta name='DC.subject' |
| 14 |
content="IVOA, Virtual Observatory, Vocabulary"/> |
| 15 |
<meta name='rcsdate' |
| 16 |
content="$Date$"/> |
| 17 |
<style type='text/css'> |
| 18 |
/* make the ToC a little more compact, and without bullets */ |
| 19 |
div.toc ul { list-style: none; padding-left: 1em; } |
| 20 |
div.toc li { padding-top: 0ex; padding-bottom: 0ex; } |
| 21 |
li { padding-top: 1ex; padding-bottom: 1ex; } |
| 22 |
td { vertical-align: top; } |
| 23 |
span.userinput { font-weight: bold; } |
| 24 |
span.url { font-family: monospace; } |
| 25 |
span.rfc2119 { color: #800; } |
| 26 |
q { color: #666; } |
| 27 |
q:before { content: "“"; } |
| 28 |
q:after { content: "”"; } |
| 29 |
.todo { background: #ff7; } |
| 30 |
|
| 31 |
/* 'link here' text in section headers */ |
| 32 |
*.hlink a { |
| 33 |
text-decoration: none; |
| 34 |
color: #fff; /* the page background colour */ |
| 35 |
} |
| 36 |
*:hover.hlink a { |
| 37 |
color: #800; |
| 38 |
} |
| 39 |
</style> |
| 40 |
</head> |
| 41 |
|
| 42 |
<body> |
| 43 |
<div class="head"> |
| 44 |
<table> |
| 45 |
<tr><td><a href="http://www.ivoa.net/" |
| 46 |
><img alt="IVOA logo" |
| 47 |
src="http://ivoa.net/icons/ivoa_logo_small.jpg" |
| 48 |
border="0"/></a></td></tr> |
| 49 |
</table> |
| 50 |
</div> |
| 51 |
|
| 52 |
<h1 property="dc:title">Issues list: Vocabularies in the Virtual Observatory</h1> |
| 53 |
<h2>IVOA Note</h2> |
| 54 |
|
| 55 |
<dl> |
| 56 |
<dt>Working Group</dt> |
| 57 |
<dd><em><a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics">Semantics</a></em></dd> |
| 58 |
|
| 59 |
<dt>This version</dt> |
| 60 |
<dd>Issues as of $Revision$, $Date$</dd> |
| 61 |
|
| 62 |
<dt>Editors</dt> |
| 63 |
<dd><a href='http://nxg.me.uk/norman/#norman' |
| 64 |
property='dc:creator' >Norman Gray</a></dd> |
| 65 |
|
| 66 |
<!-- |
| 67 |
<dt>Authors</dt> |
| 68 |
<dd> |
| 69 |
</dd> |
| 70 |
--> |
| 71 |
|
| 72 |
</dl> |
| 73 |
|
| 74 |
<h2><a id="contents" name="contents">Table of Contents</a></h2> |
| 75 |
<?toc?> |
| 76 |
<hr/> |
| 77 |
|
| 78 |
<div class='section'> |
| 79 |
<p class='title'>Introduction</p> |
| 80 |
|
| 81 |
<p>This is the list of major issues for the vocabularies work; this |
| 82 |
does not include minor issues more concerned with the fine details of |
| 83 |
maintaining and distributing the vocabularies; such minor issues might |
| 84 |
be better handled using the |
| 85 |
<a href='http://code.google.com/p/volute/issues/list' >Volute issues |
| 86 |
list</a>.</p> |
| 87 |
|
| 88 |
<p>The list is present here as a record of the points at general |
| 89 |
issue, and (post standardisation) as a reference pointing to some |
| 90 |
rationale for the design decisions in the standardised document.</p> |
| 91 |
|
| 92 |
</div> |
| 93 |
|
| 94 |
<div class='section' id='issueslist'> |
| 95 |
<p class='title'>The issues list</p> |
| 96 |
|
| 97 |
<p>The sections below are intended to be a log of the various options |
| 98 |
and eventual conclusions, rather than a summary of the arguments. For |
| 99 |
those, see the linked online discussions.</p> |
| 100 |
|
| 101 |
<p>Some of the issues below have <q>provisional resolutions</q>. |
| 102 |
These are believed to capture the sense of the on-list discussion, |
| 103 |
without being final.</p> |
| 104 |
|
| 105 |
<div class='section-nonum' id='masterformat-1'> |
| 106 |
<p class='title'>CLOSED: [masterformat-1] Format of the master vocabulary</p> |
| 107 |
|
| 108 |
<p><em>[Issue summarised here in some detail since it hasn't had much |
| 109 |
airing on-list]</em></p> |
| 110 |
|
| 111 |
<p>The distributed (and normative) SKOS files are generated to a |
| 112 |
greater or lesser extent. This might consist of a conversion from |
| 113 |
some completely different format, such as the IAUT files which |
| 114 |
originate in the easily-parsed native format of the Lexicon |
| 115 |
application which originally managed them (see Shobbrook and Shobbrook |
| 116 |
<a href='http://www.mso.anu.edu.au/library/thesaurus/introduction.html' |
| 117 |
>discussion</a>), or a relatively lightweight processing involving |
| 118 |
adding missing but mechanially inferrable relations.</p> |
| 119 |
|
| 120 |
<p>Question: what should be the format of the master files?</p> |
| 121 |
|
| 122 |
<p>Possible resolution 1: nothing mandated in the document -- the |
| 123 |
format of the master file should be whatever is most convenient, as |
| 124 |
long as the generated and distributed files are valid SKOS. [This |
| 125 |
says: there is no need for the IVOA to specify this, as it's purely |
| 126 |
private to the vocabulary maintainers]</p> |
| 127 |
|
| 128 |
<p>Possible resolution 2: SKOS, in Turtle notation, possibly requiring |
| 129 |
some post-processing to add omitted-but-inferrable relations. This is |
| 130 |
easy to read and write, and it is simple enough that it would be |
| 131 |
feasible to create from scratch a parser for the relevant subset of |
| 132 |
it, if that were somehow necessary. [This says: what we're |
| 133 |
distributing -- SKOS -- might as well be the format we edit, so we |
| 134 |
mandate that, for the sake of simplicity]</p> |
| 135 |
|
| 136 |
<p>Possible resolution 3: some more fundamental no-punctuation format, |
| 137 |
such as that for the Lexicon program. [This says: we want to be |
| 138 |
<em>completely</em> technology-agnostic, and even SKOS is too hard to |
| 139 |
parse, post-apocalypse]</p> |
| 140 |
|
| 141 |
<p><strong>Provisional resolution: option (1) above – nothing |
| 142 |
mandated</strong>. Only the distribution format is to be specified (no |
| 143 |
objections on the list).</p> |
| 144 |
|
| 145 |
<p>Discussion (such as it was): |
| 146 |
<a href='http://www.ivoa.net/forum/semantics/0802/0670.htm' >2008 Feb 4</a> |
| 147 |
(+ thread). |
| 148 |
</p> |
| 149 |
<!-- |
| 150 |
<p>No 2 seems the best balance between manageability and long-term |
| 151 |
maintainability.</p> |
| 152 |
--> |
| 153 |
|
| 154 |
</div> |
| 155 |
|
| 156 |
<div class='section-nonum' id='distformat-2'> |
| 157 |
<p class='title'>CLOSED: [distformat-2] Format of the distributed vocabularies</p> |
| 158 |
|
| 159 |
<p>Question: in which format should vocabularies be distributed?</p> |
| 160 |
|
| 161 |
<p>Possible resolution 1: the standard simply mandates that they be |
| 162 |
distributed in at least one well-known RDF format (which means either RDF/XML |
| 163 |
or Turtle, which is equivalent to N3 for this purpose). This implies that an |
| 164 |
RDF parser will, realistically, be required in order to process the |
| 165 |
vocabulary files.</p> |
| 166 |
|
| 167 |
<p>Possible resolution 2: the standard requires them to be distributed |
| 168 |
in a format which is parseable as RDF, but which is also regular |
| 169 |
enough that it's usefully interpretable as ‘normal’ XML.</p> |
| 170 |
|
| 171 |
<p><strong>Provisional resolution: option (1) above – distribution in |
| 172 |
any RDF serialisation</strong>. More rationale added to the |
| 173 |
document.</p> |
| 174 |
|
| 175 |
<p>Discussion: |
| 176 |
<a href='http://www.ivoa.net/forum/semantics/0801/0644.htm' >2008 Jan 21</a>, |
| 177 |
<a href='http://www.ivoa.net/forum/semantics/0801/0647.htm' >28</a> (+ thread), |
| 178 |
<a href='http://www.ivoa.net/forum/semantics/0802/0674.htm' >2008 Feb 4</a>. |
| 179 |
</p> |
| 180 |
|
| 181 |
</div> |
| 182 |
|
| 183 |
<div class='section-nonum' id='versioning-3'> |
| 184 |
<p class='title'>[versioning-3] Identifying vocabulary versions</p> |
| 185 |
|
| 186 |
<p>Question: do vocabulary users refer to a concept URI with an explicit |
| 187 |
version, or to a constant URI which always refers to the latest version?</p> |
| 188 |
|
| 189 |
<p>Possible resolution 1: users always refer to the same concept URI, |
| 190 |
as for example in <code>http://myvocab.org/myvocab#mytoken</code>, and |
| 191 |
this refers, either by redirection or server-internal URI rewriting, |
| 192 |
to the latest version of the vocabulary. The Dublin Core metadata set |
| 193 |
at <span class='url'>http://purl.org/dc/terms/</span> does this <span |
| 194 |
class='cite'>std:dublincore</span>.</p> |
| 195 |
|
| 196 |
<p>Possible resolution 2: users refer to a concept URI without a |
| 197 |
version; this URL returns a vocabularly with a versioned namespace |
| 198 |
(this can probably be excluded, since it violates the good practice of |
| 199 |
having a namespace be retrievable at its own URL).</p> |
| 200 |
|
| 201 |
<p>Possible resolution 3: users will refer to concepts which have a |
| 202 |
version explicit within the namespace, as for example in |
| 203 |
<code>http://myvocab.org/myvocab-v1.1#mytoken</code> (the precise |
| 204 |
location of the version number or date in the URI is arguably a |
| 205 |
distribution/maintainance detail).</p> |
| 206 |
|
| 207 |
|
| 208 |
|
| 209 |
<p>References: see <span class='cite'>berrueta08</span>, |
| 210 |
<span class='cite'>sauermann07</span>.</p> |
| 211 |
|
| 212 |
<p>Discussion: |
| 213 |
<a href='http://www.ivoa.net/forum/semantics/0801/0644.htm' >2008 Jan 21</a>, |
| 214 |
<a href='http://www.ivoa.net/forum/semantics/0801/0648.htm' >28</a> |
| 215 |
(+ threads), |
| 216 |
<a href='http://www.ivoa.net/forum/semantics/0801/0660.htm' >31</a>, |
| 217 |
<a href='http://www.ivoa.net/forum/semantics/0802/0678.htm' >2008 Feb 4</a> |
| 218 |
</p> |
| 219 |
|
| 220 |
</div> |
| 221 |
|
| 222 |
<div class='section-nonum' id='maintenance-4'> |
| 223 |
<p class='title'>CLOSED: [maintenance-4] Who maintains vocabularies?</p> |
| 224 |
|
| 225 |
<p>Question: By whom, and by what process, are vocabularies maintained?</p> |
| 226 |
|
| 227 |
<p>This is a different issue from <span |
| 228 |
class='xref'>versioning-3</span>, since that is concerned with how the |
| 229 |
versions are identified, whereas this is concerned with who it is |
| 230 |
who manages the changes which are necessary as a vocabulary evolves.</p> |
| 231 |
|
| 232 |
<p>Option 1: the vocabularies in the standardised |
| 233 |
document are regarded purely as examples, with no normative force and |
| 234 |
no specified maintenance process.</p> |
| 235 |
|
| 236 |
<p>Option 2: the document's vocabularies are normative, |
| 237 |
and the document should define a maintenance process, possibly |
| 238 |
modelled on the UCD process <span class='cite' >std:ucdmaint</span>.</p> |
| 239 |
|
| 240 |
<p>Option 3: the document's vocabularies are normative, |
| 241 |
but not claimed to be more than merely adequate. They will not be |
| 242 |
developed as part of this standard's evolution, but instead be |
| 243 |
maintained by other interest groups, either within or outwith the IVOA |
| 244 |
process.</p> |
| 245 |
|
| 246 |
<p>Are there minimal standards of curation which conforming |
| 247 |
vocabularies must abide by? For example, need we require vocabulary |
| 248 |
maintainers to use the <code><skos:changeNote></code> |
| 249 |
mechanisms, or just rely on their good sense?</p> |
| 250 |
|
| 251 |
<p><strong>Provisional resolution: Option 3</strong>. The final |
| 252 |
published standard will include a number of SKOS vocabularies produced |
| 253 |
as part of this process. These will be usable and citable, and the |
| 254 |
community will be encouraged to use them, but they will not be |
| 255 |
maintained after the standard is complete. Instead, the `owners' of |
| 256 |
the underlying vocabularies (for example the UCD maintenance group) |
| 257 |
will be encouraged to maintain the SKOS version alongside their other |
| 258 |
forms. In particular, the IVOA-T vocabulary will be developed and |
| 259 |
maintained in a parallel standard to this one.</p> |
| 260 |
|
| 261 |
<p>Discussion: |
| 262 |
<a href='http://www.ivoa.net/forum/semantics/0801/0665.htm' >2008 Jan 31</a>, |
| 263 |
<a href='http://www.ivoa.net/forum/semantics/0802/0753.htm' >2008 Feb 14</a> |
| 264 |
</p> |
| 265 |
|
| 266 |
</div> |
| 267 |
|
| 268 |
<div class='section-nonum' id='vocabset-5'> |
| 269 |
<p class='title'>CLOSED: [vocabset-5] What vocabularies are included in the standard?</p> |
| 270 |
|
| 271 |
<p>Irrespective of the resolution to issue <span |
| 272 |
class='xref'>maintenance-4</span>, there will be a set of vocabularies |
| 273 |
included in the document, either as samples, or as an initial |
| 274 |
specification. Question: What should this set contain?</p> |
| 275 |
|
| 276 |
<p>There are six vocabularies which have been associated with the |
| 277 |
draft standardisation process, namely</p> |
| 278 |
|
| 279 |
<ul> |
| 280 |
<li>the A&A journal keyword list, the IVOA AOIM list, and the 1993 |
| 281 |
IAU thesaurus, whose inclusion is as far as I can see completely |
| 282 |
uncontroversial;</li> |
| 283 |
<li>an IVOA Thesaurus based on the IAU-93, which may or may not be in |
| 284 |
this standard depending on whether people would prefer a completely |
| 285 |
separate process to develop it;</li> |
| 286 |
<li>a UCD1+ vocabulary (though this deals with a different set of |
| 287 |
concepts – namely data types – from the other vocabularies and might |
| 288 |
arguably connect poorly to them); and</li> |
| 289 |
<li>a SKOS version of the list of constellations, which is very |
| 290 |
simple, and which might reasonably find a home in this standard on |
| 291 |
that ground alone.</li> |
| 292 |
</ul> |
| 293 |
<p>In addition, there are multiple informal keyword lists associated |
| 294 |
with the VOEvent arena (see Roy's message and Rob's). These haven't |
| 295 |
been SKOSified at all, and Rick's excellent suggestion is that these |
| 296 |
be left as homework for the VOEvent group.</p> |
| 297 |
|
| 298 |
<p><strong>Provisional resolution: include all five/six</strong>. The |
| 299 |
A&A, AOIM, UCD1, IAU-93 and constellations vocabularies will be |
| 300 |
finished and immediately useable (see the resolution on maintenance in |
| 301 |
<a href='#maintenance-4'>[maintenance-4]</a>). The IVOAT vocabulary |
| 302 |
will be developed in a parallel process to this vocabularies standard: |
| 303 |
it will be referred to, and a snapshot of it <em>may</em> be included |
| 304 |
in the standard, but it will be clearly marked as a work-in-progress.</p> |
| 305 |
|
| 306 |
<p>Discussion: |
| 307 |
<a href='http://www.ivoa.net/forum/semantics/0801/0665.htm' >2008 Jan 31</a>, |
| 308 |
<a href='http://www.ivoa.net/forum/semantics/0802/0682.htm' >2008 Feb 4</a>, |
| 309 |
<a href='http://www.ivoa.net/forum/voevent/0802/0654.htm' >2008 Feb 4 |
| 310 |
(VOEvent list)</a>, |
| 311 |
<a href='http://www.ivoa.net/forum/semantics/0802/0711.htm' >7</a>, |
| 312 |
<a href='http://www.ivoa.net/forum/semantics/0802/0753.htm' >14</a>; |
| 313 |
<a href='http://www.ivoa.net/twiki/bin/view/IVOA/VocabulariesWorkingArea' |
| 314 |
>wiki page</a>. |
| 315 |
</p> |
| 316 |
|
| 317 |
</div> |
| 318 |
|
| 319 |
<div class='section-nonum' id='mappings-6'> |
| 320 |
<p class='title'>[mappings-6] Inclusion of mappings in vocabularies</p> |
| 321 |
|
| 322 |
<p>Should mappings between vocabularies be in this standard, and if |
| 323 |
so, how closely bound should they be to the vocabulary itself?</p> |
| 324 |
|
| 325 |
<p>The early-2008 editors draft for the SKOS standard <span |
| 326 |
class='cite'>std:skosref</span> included inter-vocabulary mappings, |
| 327 |
which were hitherto separate from the intra-vocabulary links in the |
| 328 |
SKOS core. The question of mappings in the SKOS standard is still |
| 329 |
(early 2008) in flux.</p> |
| 330 |
|
| 331 |
<p>Question: how do we accomodate this uncertainty in the IVOA |
| 332 |
Vocabularies standard? And how do we advise mappings to be published?</p> |
| 333 |
|
| 334 |
<p>Consideration 1: The mappings spec is still in flux, and likely to |
| 335 |
remain so for some time after the SKOS core document is |
| 336 |
standardised</p> |
| 337 |
|
| 338 |
<p>Consideration 2: Norman would hope to see the situation developing |
| 339 |
where there are multiple third-party mappings between vocabularies, |
| 340 |
maintained by specific communities, or which describe mappings at |
| 341 |
different levels of granularity, or which represent significant |
| 342 |
(publication-worthy?) labour on the part of individuals, adding value |
| 343 |
to the network of vocabularies.</p> |
| 344 |
|
| 345 |
<p>Suggested resolution: include mappings as non-normative parts of |
| 346 |
this standard, published alongside, but separate from, the normative |
| 347 |
SKOS versions of the vocabularies, and using whatever are the |
| 348 |
then-current best mapping practices. In this standard, and in the |
| 349 |
best-practice guidelines we include, we should proscribe inter-vocabulary |
| 350 |
mappings being published as part of a vocabulary.</p> |
| 351 |
|
| 352 |
<p>Crucially, vocabularies and the mappings between them are |
| 353 |
conceptually separate entities, although they will in practice likely be |
| 354 |
maintained together.</p> |
| 355 |
|
| 356 |
</div> |
| 357 |
|
| 358 |
</div> |
| 359 |
|
| 360 |
<div class='appendices'> |
| 361 |
<div class='section-nonum' id='bibliography'> |
| 362 |
<p class='title'>Bibliography</p> |
| 363 |
<?bibliography rm-refs ?> |
| 364 |
</div> |
| 365 |
</div> |
| 366 |
|
| 367 |
</body> |
| 368 |
</html> |
Parent Directory
| 
Revision Log
