/[volute]/trunk/projects/theory/snapdm/doc/note/SimDB-note.html
ViewVC logotype

Contents of /trunk/projects/theory/snapdm/doc/note/SimDB-note.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 264 - (show annotations)
Thu Apr 24 06:34:40 2008 UTC (12 years, 7 months ago) by gerard.lemson
File MIME type: text/html
File size: 25495 byte(s)
Updates. Added @@TODO ... @@ indicating who might write the corresponding section.
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <html>
4 <head>
5 <title>IVOA Working Group - Internal Draft</title>
6 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
7 <meta name="keywords" content="IVOA, International, Virtual, Observatory, Alliance" />
8 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
9 <meta name="maintainedBy" content="IVOA Document Coordinator, ivoadoc@ivoa.net" />
10 <link rel="stylesheet" href="http://ivoa.net/misc/ivoa_wg.css" type="text/css" />
11 </head>
12
13 <body>
14 <div class="head">
15 <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>
16 <h1>Simulation Database (SimDB)<br/>
17 Version 0.x</h1>
18 <h2>IVOA Theory Interest Group <br />Internal Draft 2008 April 19 </h2>
19
20
21 <dt>This version:</dt>
22 <dd><a href="http://www.ivoa.net/Documents/...">
23 http://www.ivoa.net/Documents/...</a></dd>
24
25 <dt>Latest version:</dt>
26
27 <dd><a href="http://www.ivoa.net/Documents/latest/...">
28 http://www.ivoa.net/Documents/latest/...</a></dd>
29
30 <dt>Previous versions:</dt>
31 <dt>Interest Group:</dt>
32 <dd><a href="http://www.ivoa.net/twiki/bin/view/IVOA/IvoaTheory"> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaTheory</a></dd>
33 <dt>Author(s):</dt>
34 <dd>
35 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/GerardLemson">Gerard Lemson</a> (editor)<br />
36 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/LaurentBourges">Laurent Bourges</a><br />
37 ?<a href="http://www.ivoa.net/twiki/bin/view/IVOA/NormanGray">Norman Gray</a>? @@TODO ask Norman@@<br />
38 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/PatriziaManzato">Patrizia Manzato</a><br />
39 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/RickWagner">Rick Wagner</a><br />
40 <a href="http://www.ivoa.net/twiki/bin/view/IVOA/RickWagner">Herv&eacute; Wozniak</a><br />
41
42 others, fewer?<br /></dd>
43
44 <hr/></div>
45
46 <h2><a name="abstract" id="abstract">Abstract</a></h2>
47 <p>In this note we propose that the IVOA develop a standard protocol for discovering simulations.
48 We will call this the Simulation Database (SimDB). Implementations of the SimDB will allow users to query for
49 results of simulations in quite some detail and will provide links to services for accessing these
50 simulations. </p>
51 <p>The results presented in this note, which form the core of the peoposed standard, are one half of a concerted effort of the theory Interest Group that originally went by the name
52 S<i>imple Numerical Access Protocol</i> (SNAP), and is now split up in two parts. The second part defines protocols
53 for accessing the simulations data products themselves. This part will be written up in a separate Note
54 (Gheller, Wagner et al, in preparation), under the name Simulation Data Access Protocol (SimDAP).
55 </p>
56 <p>The current proposal is built around a UML data model describing simulations, a representation (mapping) of this model as a relational
57 database schema and a mapping to an XML schema.
58 We propose the relational schema to be the outer facade of a SimDB-TAP implementation which is to be queried using
59 <a href="http://www.ivoa.net/internal/IVOA/IvoaVOQL/ADQL-20080415.pdf">ADQL</a> @@ TODO update the ADQL link to later versions @@. The XML schema provides type definitions from
60 which a machine readable serialisations of the model may be constructed. The schema also defines root elements for documents
61 describing SimDB-resources. The SimDB should return such documents for identified SimDB-Resources upon request, as an
62 alternative to the tabular (VOTable) results of ADQL queries.
63 In case updates are supported by a SimDB implementation, such documents may be sent
64 </p>
65 <p>
66 This Note describes use cases and requirements and the approach we have taken to define a specification
67 that and current state of the results. We feel that the results are
68 sufficiently far evolved that they can start following the formal IVOA standardisation track.
69 To this end it could be turned over to one of the existing working groups. If that is the decisions we feel
70 that the data modelling WG is closest to its scope, but there exist very strong links to Registry, Semantics, ADQL
71 and DAL as well. One might argue that a targeted WG for this effort alone might be as appropriate.
72 We leave the decision about this to the IVOA exec.
73 </p>
74
75
76
77 <div class="status">
78 <h2><a name="status" id="status">Status of this Document</a></h2>
79 This is a Note. The first release of this document was 2008 April 19.
80 <p></p><br />
81
82 <!-- Choose one of the following (and remove the rest)-->
83 <!--Note-->
84 <p>This is an IVOA Note expressing suggestions from and opinions of the authors.<br/>
85 It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory.
86 It should not be referenced or otherwise interpreted as a standard specification.</p>
87
88
89 A list of <a href="http://www.ivoa.net/Documents/">current IVOA Recommendations and other technical documents</a> can be found at http://www.ivoa.net/Documents/.
90
91 </div><br />
92
93 <h2><a name="acknowledgments" id="acknowledgments">Acknowledgments</a></h2>
94 <p>We thank various persons for useful discussions in the course of this work. First the participants of the
95 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/CambridgeTheoryWorkshopFeb06">Feb 2006 theory
96 workshop</a> in Cambridge, UK, where this work was started. Second the participants of the
97 <a href="http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/GarchingSNAPWorkshop200704">April 2007 SNAP workshop</a> in
98 Garching, Germany, where the design started taking shape. Then we want to thank particularly the following persons
99 for useful discussions and feedback: Jeremy Blaizot, Klaus Dolag, Ray Plante, Volker Springel. We finally want to thank
100 participants to the theory sessions in the interoperability meetings in Victoria, Moscow, Beijing and Cambridge where parts
101 of this work was discussed.
102 </p>
103 <h2><a id="contents" name="contents">Contents</a></h2>
104 <div class="head">
105 <ul class="toc">
106 <li><a href="#abstract">Abstract</a></li>
107 <li><a href="#status">Status</a></li>
108 <li><a href="#acknowledgments">Acknowledgments</a></li>
109 <li><a href="#contents">Contents</a></li>
110 <li><a href="#sec1">1. Executive Summary</a></li>
111
112 <li><a href="#sec2">2. Second Section</a></li>
113 <ul class="toc">
114 <li><a href="#sec2_1">2.1 TwoPointOne ...</a></li>
115 <li><a href="#sec2_2">2.2 ..</a></li>
116 <ul class="toc">
117 <li><a href="#sec2_2_1">2.2.1 ..</a></li>
118 </ul>
119 </ul>
120
121 <li><a href="#sec3">3. Data model</a></li>
122
123 <br/>
124 <li><a href="#appA">Appendix A: ...</a></li>
125 <br/>
126 <li><a href="#references">References</a></li>
127 </ul>
128 </div>
129 <hr/>
130
131
132 <br/>
133 <h2><a name="sec1">1. Executive summary</a></h2>
134 <p>
135 We propose to derive two WG projects from what was so far the
136 SNAP project of the theory interest group: SimDB and SimDAP.
137 In this note we discuss the first of these, SimDB, in some detail.
138
139 </p>
140 <h3> Simulation Database (SimDB)</h3>
141 <p>We propose to develop a standard specification project, called the "Simulation Database" (SimDB).
142 It is based on the description+discovery part of the old
143 SNAP project. Its normative deliverables are
144 <ul>
145 <li> A data model for describing simulations.<br/>
146 Following SNAP we keep concentrating
147 on 3+1D simulations, with which we mean simulations modelling a
148 space-time sub-volume of the universe OF ANY SIZE, so not only large
149 scale structure, galaxy clusters, but everything down to asteroid collisions etc.
150 As the model <i>describes</i> simulations, it may be called a meta-data model.
151 It will be a logical model in the sense of standard data modelling approaches @@TODO add some references@@,
152 and is based on an analysis, or domain model which is presented but not normative.
153 The logical model is presented in fully detailed and documented UML2, serialised
154 to XMI 2.1, created using the MagicDraw 12.1 Community edition tool.
155 The data model is using a small subset of UML2 and has some UML profile
156 extensions added. Together this can be seen as a domain specific language,
157 and this can be formalised in a UML Profile. We will propose using such a profile
158 to the DM working group as a general approach for DM efforts.
159 </li>
160 <li>A query protocol based on the logical model.
161 <br />We propose this to have at least an ADQL version.
162 To this end we will provide a relational mapping.
163 This physical model is completely derived from the SimDB logical model using rules
164 implemented as a pipe-line of XSLT2 scripts working on the XMI representation of
165 the UML. The scripts will produce relational database DDL scripts defining the
166 database schema. That schema itself is not normative, instead we will define the
167 replies to TAP metadata queries. We provide implementaiton scenarios in the text below,
168 for the case of someone using the results from this project completely and for the
169 case of someone implementing a SimDB on top of a legacy database.
170 </li>
171 <li> a messaging format for sending instances of the various components
172 in the data model around.
173 <br />This format will be based on a number of XML
174 schema documents (XSDs), one of which contains the root elements defining valid SimDB resources.
175 This requires a mapping from the UML to XSD.
176 This mapping will take the form of one or more XSLT documents.
177 </li>
178 <li> An IVOA working draft document describing these components.
179 <br />This will be based on the current document.</li></ul>
180 </p>
181 <p>
182 Then we provide some non-normative solutions that can be taken over for generic
183 data models (this is ofcourse also true for the UML/XMI+XSLT approach for the
184 normative standards).
185 <ul>
186 <li> The XSLT scripts we propose above do not work on the XMI itself, but on
187 an intermediate representation of the UML data model. This is an XML dialect
188 based on a schema we define and which captures the UML profile more directly.
189 XMI is very generic and rather cumbersome to work with. The representation of
190 the UML in our intermediate XML form is much more readable and XSLT based on it
191 is much simpler. It also allows easier adaptation to future modifications in UML,
192 or to tools whose XMI representation is different from the standard. We only need
193 to update the XMI->Intermediate XSLT transformation scripts. Not the more complex
194 transformations to the other official representations.
195 We will propose a similar approach to the DM WG.
196 </li>
197 <li> We will provide XMI->Java+JPA+JAXB transformation scripts in XSLT (properly, intermediate->Java).
198 These scripts generate Java classes corresponding to the types (Class, DataType, Enumeration)
199 in UML. These classes are annotated with Java Persistence Architecture (JPA)
200 and Java Architecture for XML Binding (JAXB) attributes to assist in the transformation
201 between relational database and XML representations.
202 Similar scripts can be written for C#. C# allows the same annotations as Java 5 supports
203 already for longer. For persistence we will likely use Linq, which seems similar to JPA.
204 </li>
205 <li>We propose an approach for including application specific and legacy simulation databases
206 in this framework. This approach follows the "global-as-view" approach to information
207 integration (see for example http://www.deg.byu.edu/papers/PODS.integration.pdf;
208 Leonid Kalinichenko from the RVO is an expert in this field).
209 Implementors with an existing relational database schema may be able to define database
210 views which implement the relational representatiopn of the SimDB data model,
211 and in this way provide a simple way to support querying of their database using ADQL.
212 </li></ul></p>
213 <h4>organisation</h4>
214 <p>
215 The SimDB is ready to be transferred to the DM WG.
216 <br />We propose that Gerard Lemson keeps leading this effort (as main editor), also when it is moved
217 to that WG. The DM WG's chair (Mireille Louys) will be responsible all WG-chair
218 issues associated with moving a specification through the document process.
219 The people at the bottom will be part of a "tiger team" to push the standard to RFC.
220 We may want to expand this group with an expert from each of the WGs mentioned below.
221 </p>
222 <p>
223 We have been discussing the data model for some time now.
224 Various projects (Italy, USA, France and Germany) have implementations that are similar
225 to the envisioned SimDB. We believe that by autumn 2008 it can go to RFC.
226 Patriza Manzato and Rick Wagner will have reference implementations based on existing DBs,
227 so will various projects in France (Lyon: Jeremy Blaizot and Laurent Bourges;
228 Galmer database: Igor Chillingarian) and GAVO.
229 </p>
230 <p>
231 Other relevant working groups for this process are Registry, ADQL and Semantics, possibly DAL.
232 Registry because the simulation database is similar to a registry. We can
233 learn from implementations and the registry interface. Also, we (think we) may need an
234 extension to the IVO Identifier in the implementation of references in SimDB.
235 ADQL because we propose it to be the standard (main) query interface to a SimDB implementation.
236 Semantics because our model includes usage of semantic vocabularies, maybe full ontologies
237 DAL because we our proposal for using ADQL in the query phase requirs a version of
238 the TAP protocol for defining the interface.
239 We would like to include a person from each of these WGs in the tiger team.
240 Our wishes are: Ray Plante (Registry), ? (ADQL), Norman Gray (Semantics), (?) TAP.
241 Ray and Norm have contributed to early discussions about SNAP.
242 </p>
243 <p>
244 Of these other efforts it seems TAP offers the main risk for the SimDB standard to go to
245 RFC by the Autumn. What may help us is that we do not need all the details of TAP.
246 In particular the information_schema approach allowing users to
247 query for the data model is not required as it is part of SimDB specification.
248 We mainly need a prescription for sending ADQL queries to the SimDB, and what the
249 format of results should be.
250 Since we expect meta-data databases to be relatively small (compared to
251 say an SDSS or Millennium database), we expect fewer, if any problems with
252 performance and can stick to synchronous behaviour at first.
253 </p>
254 <p>
255 We may need some explicit registry-interface like features such as returning a
256 complete XML document according to the messaging format of the SimDB data model.
257 Other issues will come up during the next phase of the discussions.
258 </p>
259
260 <h2>Simulation Data Access Protocol (SimDAP)</h2>
261 <p>
262 The second spin-off of the SNAP project we propose we rename to <i>Simulation Data Access Protocol</i> (SimDAP).
263 It deals with accessing the data after discovery by some means,
264 likely trough an implementation of a Simulation Database.
265 It should handle special services such as cut-out, projection,
266 extraction (AMR-like cut-outs, produces regular grids), but also staging etc.
267 It should also deal with data formats. Claudio Gheller (Italy) is leading
268 this effort with close help of Rick Wagner (USA).
269 </p>
270 <p>
271 This project needs more fleshing out and is hopefully ready to be transmitted
272 to a WG, likely DAL by the Autumn interop.
273 </p>
274 <h2>Connections between SimDB and SimDAP</h2>
275 <p>
276 The two projects are connected as follows:
277 The meta-data formats to be included in SimDAP messages are derived from
278 the data model of the SimDB.
279 Vice versa, the SimDB will include a component describing
280 which SimDAP services are applicable/available for a given simulation.
281 </p>
282
283 <h2><a name="sec2"> </a> 2 Use cases, scenarios, requirements </h2>
284 <p>This document presents a model for describing certain types of numerical computer simulations
285 and certain types of simulation post-processing products. The model is to be used in the query
286 part of the Simple Numerical Access Protocol (SNAP, TBD think of better name?], and in discovery
287 of interesting SNAP services in the first place.
288 We only consider simulations for systems that represent a space-time sub-volume of the universe
289 and (part of) its material contents. In general these simulations will evolve this system forward
290 in time and are able to produce snapshots, representing the state of the system at a number of
291 consecutive times. These direct, raw results of simulations we call Level-0 products, following
292 similar terminology for observations.
293 SNAP also covers Level-1 products, which consist of the results of certain types of post-processing
294 of simulations, namely those products that in some form represent a spatial sub-volume of the universe.
295 We do not make any restrictions on the type of systems being simulated, or the size of the
296 simulation, or the way the system is represented in the simulation code and results. We also
297 make no restrictions on the type of "observables" produced by the simulations. The SNAP
298 protocol includes online services that process level-0 or level-1 results and produce
299 (by definition) other level-1 results. The allowed services deal with selecting the results in a
300 sub-volume of the complete result, projections onto a 2-dimensional mesh, ... [TBC]
301
302 </p>
303 We have assembled a list of explicit use cases and scenarios from which we derive
304 requirements for the current model and the SNAP protocol.
305
306 <p>
307 Scientific goals and corresponding questions to a repository of simulations:
308 </p><ul>
309 <li> Scientific goal: investigate baryon wiggles in the evolved density field<br/>
310 Query: Return all cosmological, pure dark matter, N-body simulations with WMAP 3 initial
311 conditions and a box size of at least 1000 Mpc comoving, containing snapshots at about
312 10 redshifts between 3 and 0.
313 </li>
314 <li> Scientific goal: investigate whether observed structures in X-ray cluster that seem to
315 indicate turbulence, can truly be that.<br> Query: return all hydro-dynamical simulations of
316 galaxy clusters of mass at least that have a model for viscosity included in the simulation.
317 Moreover, return only those simulations that have associated to them an online visualisation
318 service that can produce projected temperature and pressure maps.
319 </li>
320 <li> Scientific goal: interpret the possible histories of an observed galaxy merger to calculate
321 possible star formation episodes and compare these to the observed stellar populations.<br>
322 Query: Return all simulations of galaxy mergers where the component galaxies have a particular
323 mass ratio and where there are enough snapshots to follow the evolution over a few Gyr.
324 </li>
325
326 <li> Scientific goal: compare the luminosity function of galaxies in the SDSS survey with those
327 in synthetic catalogues.<br>Query: Select all cosmological simulations that have produced as
328 secondary product synthetic galaxy catalogues on a light-cone and provide those via an SQL (ADQL?)
329 query interface.
330 </li>
331 <li> ...
332 </li>
333 </ul>
334 <br/>
335
336 <h2><a name="sec3">3. Approach</a></h2>
337 <p>We describe our approach to developing the various products of the SimDB specification.
338 </p>
339
340 <h3><a name="sec3.1">3.1 The <i>universe of discourse</i></a></h3>
341 <p>
342 The first task in our data modelling effort is to define whic part of the world we are trying to model. In the field this is referred to as defining the <i>universe of discourse</i>. In the case at hand our ultimate goal is to describe simulaitons and their results in sufficient detail that informative questions can be we are trying to <br /><br />For the purpose of this specification we consider a simulation as the execution of software
343 that produces a representation of a spatial system, and possibly follows its evolution form
344 one state to the next by approximating the true physical processes acting on the system with
345 numerical algorithms. A description of such a simulation can be provided by giving the representation
346 of the state of the system at each point of time, of the physics being modelled as differential
347 equations and the way these act on the representation variables. It requires initial conditions
348 and parameters describing the physics as well as numerical approximations. For discovery purposes
349 it is also important to be able to provide summarising information about the results.
350 </p>
351 In the design of the model it is useful to think about the steps a user might go through
352 when querying a database system in various "drilling down" steps. For example the following
353 questions might be asked :
354
355 <ul>
356 <li>What system/object is being simulated?</li>
357 <li>What physical processes are included?</li>
358 <li>How is the system being represented in the simulation
359 (particles (Langrangian), (adaptive) mesh (Eulerian)), both, other?</li>
360 <li>Per process:<ul>
361 <li>How are the physical processes implemented ?</li>
362 <li>Characterise the numerical approximations (.e.g. resolution, softening parameter)</li></ul></li>
363 <li>What observables are available for the system/object, possibly as function of time?
364 As it is a spatial system, at least size, center-of-mass position.</li>
365 <li>What observables are available for the constituents, i.e. what is the schema of the atomic objects?</li>
366 <li>Per snapshot, per atomic object type, per variable:
367 <ul>
368 <li>Characterise the possible values</li>
369 <li>Characterise the result</li></ul></li>
370 <li>Are post-processing results available?</li>
371 <li>Are services/applications available working on the results?</li>
372 <li>Which code ran the simulation?</li>
373 <li>What were values of physical parameters?</li>
374 <li>How were initial conditions created, what parameters?</li>
375 </ul>
376 </p>
377 <h3><a name="profile"/>3.2 UML</h3>
378 @@TODO Gerard@@
379
380 <h4>3.2.1 IVOA UML Profile</h4>
381 <h4>3.2.2 XMI</h4>
382
383
384 <h3>3.3 Serialisations</h3>
385 @@ TODO Gerard @@
386 <h4>3.3.1 Relational mapping</h4>
387 <h4>3.3.2 XML schema</h4>
388
389 <h3>3.4 XSLT pipeline</h3>
390 @@ TODO Laurent @@
391
392
393 <br /><h2>4. Results</h2>
394 <p>
395 The actual models and their physical representations are provided using links
396 to their location in an SVN repository under Google Code.
397 </p>
398 <h3><a name="analysis"/>4.1 Analysis model</h3>
399 The analysis model is an abstract representation of the <a href="#sec3.1">universe of discourse</a> (UoD).
400 It is a UML model, with emphasis on the concepts and their relationships in the UoD, less on details
401 such as attributes. @@TODO create a version and add it to volute@@.
402 <h3><a name="logical"/>4.2 SimDB logical data model</h3>
403 <p>
404 The logical data model is a fully detailed model of the application domain.
405 It is represented as a set of UML diagrams, which we created using MagicDraw Community Edition 12.1 and stored as an
406 XMI file in the GoogleCode
407 SVN repository: <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/SNAP_Simulation_DM.xml">
408 SNAP_Simulation_DM.xml</a> @@TODO should change all occurrences of names with SNAP to using SimDB?@@
409 JPG representations of the model can be found in <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/images/">this</a>
410 directory. @@TODO find proper representation image of the complete model. Possibly color packages differently.@@
411 </p>
412 <h3><a name="intermediate"/>4.3 Intermediate representation</h3>@@TODO find a different name@@
413 <br />
414 We introduce our own XML format, defined by the XML schema in
415 <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/res/intermediateModel.xsd">intermediateModel.xsd</a>,
416 for representing the logical model. For the time being we call this the <i>intermediate representation</i>.
417 The first step in the generation pipeline is a translation of the XMI to an XML document following this format.
418 This transformation is implemented in the
419 <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/res/xmi2intermediate.xsl">xmi2intermediate.xsl</a>
420 XSLT script. The latest version of the intermediate representation for the SimDB data model can be found in
421 <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/output/SNAP_Simulation_DM_INTERMEDIATE.xml">this location</a>.
422 All other generation scripts work on this intermediate representation, not on the XMI document.
423 Variations in tool-generated XMI, or different versions of XMI can now be supported by an appropriately adjusted
424 XSLT script.
425 One reasons why this may be useful is that are different tools may produce different versions or different
426 dialects of XMI. Another reason for this representation is that XMI is a rather complex representation of a UML
427 model. Since we are using a rather restricted <a href="#profile">profile</a> we do not need this generality, and
428 this allows us to represent the model using XML documents that are much easier to handle with XSLT.
429 <h3><a name="relationalschema"/>4.4 Relational schema</h3>
430 <h3><a name="xmlschema"/>4.5 XML schema</h3>
431 <h3><a name="xhtml"/>4.6 XHTML</h3>
432 <h3>4.7 Java: JPA+JAXB</h3>
433
434
435 <h2>5. Reference implementations</h2>
436 <h3>5.1 France</h3>
437 @@ TODO Laurent @@
438 <h3>5.2 Germany</h3>
439 @@ TODO Gerard @@
440 <h3>5.3 Italy</h3>
441 @@ TODO Patrizia @@
442 <h3>5.4 USA</h3>\
443 @@ TODO Rick @@
444 <br/>
445 <h2><a name="references">References</a></h2>
446
447 <p><a name="references_1">[1] Author(s), <i>Title</i>
448 <br/><a href="http://">http://</a>
449 </p>
450
451
452
453 </body></html>

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26