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

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

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 452 by gerard.lemson, Fri May 9 16:16:54 2008 UTC revision 453 by gerard.lemson, Mon May 12 08:31:24 2008 UTC
# Line 8  Line 8 
8          <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />          <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
9          <meta name="maintainedBy" content="IVOA Document Coordinator, ivoadoc@ivoa.net" />          <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" />    <link rel="stylesheet" href="http://ivoa.net/misc/ivoa_wg.css" type="text/css" />
11    <link rel="stylesheet" href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/css/simdb-note.css" type="text/css">    <link rel="stylesheet" href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/css/simdb-note.css" type="text/css" />
12  </head>  </head>
13    
14  <body>  <body>
# Line 136  Line 136 
136          <ul class="toc">          <ul class="toc">
137          <li><a href="#sec5_1">5.1 Overview</a></li>          <li><a href="#sec5_1">5.1 Overview</a></li>
138          <li><a href="#sec5_2">5.2 Normalisation</a></li>          <li><a href="#sec5_2">5.2 Normalisation</a></li>
139          <li><a href="#sec5_3">5.3 Target</a></li>          <li><a href="#sec5_3">5.3 Model content</a></li>
140          <li><a href="#sec5_4">5.4 Characterisation</a></li>          <li><a href="#sec5_3_1">5.3.1 Resource hierarchy</a></li>
141          <li><a href="#sec5_5">5.5 Semantics</a></li>          <li><a href="#sec5_3_2">5.3.2 Object types</a></li>
142            <li><a href="#sec5_3_3">5.3.3 Target</a></li>
143            <li><a href="#sec5_3_4">5.3.4 Characterisation</a></li>
144            <li><a href="#sec5_3_5">5.3.5 Semantics</a></li>
145            <li><a href="#sec5_3_6">5.3.6 Units</a></li>
146            <li><a href="#sec5_3_7">5.3.7 Services</a></li>
147          </ul>          </ul>
148                    
149  <li><a href="#sec6">6 Physical models</a></li>  <li><a href="#sec6">6 Physical models</a></li>
# Line 332  Line 337 
337  </p>  </p>
338    
339  <!-- ++++++++++++++++++++++++ -->  <!-- ++++++++++++++++++++++++ -->
340  <h2><a name="sec2"/> </a>2 Overview</h2>  <h2><a name="sec2"/> 2 Overview</h2>
341    
342  <h3><a name="sec2_1"/>2.1 SNAP &rArr; SimDB + SimDAP</h3>  <h3><a name="sec2_1"/>2.1 SNAP &rArr; SimDB + SimDAP</h3>
343  <p>This document presents a model for describing certain types of numerical computer simulations  <p>This document presents a model for describing certain types of numerical computer simulations
# Line 354  Line 359 
359  a simulation of the evolution of a globular cluster using a combination of tools, together simulating  a simulation of the evolution of a globular cluster using a combination of tools, together simulating
360  the various types of physics <em class="todo">@@ TODO reference to MODEST-like activities</em>; or  the various types of physics <em class="todo">@@ TODO reference to MODEST-like activities</em>; or
361  simulations calculating the few seconds of a super nova explosion in full 3D.    simulations calculating the few seconds of a super nova explosion in full 3D.  
362  </p  </p>
363  <p>  <p>
364  In general these simulations will evolve this system forward  In general these simulations will evolve this system forward
365  in time and are able to produce <i>snapshots</i>, representing the state of the system, a 3D volume of space,  in time and are able to produce <i>snapshots</i>, representing the state of the system, a 3D volume of space,
# Line 368  Line 373 
373  to a cosmological simulaiton, or a synthetic galaxy catalogue derived from the cluster catalogue using  to a cosmological simulaiton, or a synthetic galaxy catalogue derived from the cluster catalogue using
374  halo occupation distribution models (HODs) or semi-analytical models (SAMs).  halo occupation distribution models (HODs) or semi-analytical models (SAMs).
375  </p>  </p>
376    <p>
377  We do not make any restrictions on the type of systems being simulated, or the size of the  We do not make any restrictions on the type of systems being simulated, or the size of the
378  simulation, or the way the system is represented in the simulation code and results. We also  simulation, or the way the system is represented in the simulation code and results. We also
379  make no restrictions on the type of "observables" produced by the simulations.  make no restrictions on the type of "observables" produced by the simulations.
# Line 479  Line 485 
485  when querying a database system in various "drilling down" steps. For example the following  when querying a database system in various "drilling down" steps. For example the following
486  questions might be asked :  questions might be asked :
487  </p>  </p>
488    <p>
489  <ul>  <ul>
490  <li>What system/object is being simulated?</li>  <li>What system/object is being simulated?</li>
491  <li>What physical processes are included?</li>  <li>What physical processes are included?</li>
# Line 590  Line 597 
597  <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/SimDB_DM.xml">HTML documentation</a> which we generated from the XMI  <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/SimDB_DM.xml">HTML documentation</a> which we generated from the XMI
598  representation with the XSLT pipeline described in <a href="#appB">Appendix B</a>. This generated documentation file contains  representation with the XSLT pipeline described in <a href="#appB">Appendix B</a>. This generated documentation file contains
599  the explicit description of all of the elements in the model and forms the reference documentaiton document for the model.    the explicit description of all of the elements in the model and forms the reference documentaiton document for the model.  
600  <h3><a name="sec5_1"/>5.1 Overview</h4>  </p>
601    <h3><a name="sec5_1"/>5.1 Overview</h3>
602  <p>  <p>
603  The logical data model is a fully detailed model of the application domain. It is to form the basis of physical  The logical data model is a fully detailed model of the application domain. It is to form the basis of physical
604  models, representing the model in various computational environments.  models, representing the model in various computational environments.
# Line 601  Line 609 
609  JPG representations of the model can be found in <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/images/">this</a>  JPG representations of the model can be found in <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/images/">this</a>
610  directory. <em class="todo">@@TODO find proper representation image of the complete model. Possibly color packages differently.@@</em>  directory. <em class="todo">@@TODO find proper representation image of the complete model. Possibly color packages differently.@@</em>
611  </p>  </p>
612  <h3><a name="sec5_2"/>5.2 Normalisation</h4>  <h3><a name="sec5_2"/>5.2 Normalisation</h3>
613    <p>
614    </p>
615  <h3><a name="sec5_3"/>5.3 Model contents</h3>  <h3><a name="sec5_3"/>5.3 Model contents</h3>
616    <p></p>
617  <h4><a name="sec5_3_1"/>5.3.1 Resource hierarchy</h4>  <h4><a name="sec5_3_1"/>5.3.1 Resource hierarchy</h4>
618  <p>  <p>
619  At the root of the SimDb data model is an abstract class called Resource, in the rest  At the root of the SimDb data model is an abstract class called Resource, in the rest
620  of this document we will refere to this as SimDB/Resource.  of this document we will refere to this as SimDB/Resource.
621  It represents the different types of highest level meta-data objects to be stored in a SimDB.  It represents the different types of highest level meta-data objects to be stored in a SimDB.
# Line 643  Line 654 
654  Some more thoughts on this subject will be given in <a href="#">section ???</a> <em class="todo">@@ TODO add proper section and href@@</em> mentioned above.  Some more thoughts on this subject will be given in <a href="#">section ???</a> <em class="todo">@@ TODO add proper section and href@@</em> mentioned above.
655  </p>  </p>
656    
657  <h4><a name="sec5_3_2"/>5.3.2 Target</h4>  <h4><a name="sec5_3_2"/>5.3.2 Object types</h4>
658    <p>
659    </p>
660    
661  <h4><a name="sec5_3_3"/>5.3.3 Characterisation</h4>  <h4><a name="sec5_3_3"/>5.3.3 Target</h4>
662    <p>
663    The first question most people want to know about a simulations is: "what is being simulated?".
664    The answer should correspond to a real (astronomical) object, or collection of objects,
665    or  possibly a physical process. For SimDB to answer such questions implies that publishers must be
666    able to describe these concepts in the model.
667    We have introduced the TargetObjectType and TargetProcess classes for this.... <em class="todo">@@ TODO expand @@</em>.
668    </p>
669    
670  <h4><a name="sec5_3_4"/>5.3.4 Semantics</h4>  <h4><a name="sec5_3_4"/>5.3.4 Characterisation</h4>
671    <p>
672    </p>
673    
674  <h4><a name="sec5_3_5"/>5.3.5 Units</h4>  <h4><a name="sec5_3_5"/>5.3.5 Semantics</h4>
675    <p>
676    There are many instances in the data model where we need to describe elements of the
677    SimDB/Resource-s explicitly, because we do not have implicit information based on the context.
678    Examples are the various properties of object types, the target objects and processes etc.
679    Apart from a name and a description we then frequently add
680    an attribute which is supposed to "label" the element according to an assumed standard list of terms.
681    We model this using the <pre>&lt;&lt;ontologyterm&gt;&gt;</pre> stereotype. Attributes with this stereotype
682    are assumed to take their values form such a predefined "ontology".
683    
684    </p>
685    
686  <h4><a name="sec5_3_6"/>5.3.6 Services</h4>  <h4><a name="sec5_3_6"/>5.3.6 Units</h4>
687  The goal of the SimDB specification is to define a protocol for querying interesting simulations and related SimDB/Resource-s.  <p>
688    The current (May 2008 <em class="todo">@@ TODO update when necessary @@</em>) version of the model
689    allows publishers to specify numerical quantities using a real value and a unit.
690    I.e. we do not prescribe units for particular quantities.
691    Allowing this flexibility in units assignment does pose a problem for a query interface that allows user to query on
692    characterisation values and other numerical quantities. ADQL does not include units for example, but a user
693    can not assume that every publisher will use the same unit for for example the typical size of a simulation box.
694    This is even worse of course for the characterisation values of properties that have to be defined
695    in the model and can have any kind of assumed unit.
696    </p>
697    <p>
698    We believe we should treat units as a special semantic vocabulary, possibly an ontology.
699    This implies we push its development off to elsewhere for now, and assume we can
700    at some point use a standard list of units in a similar way to the other ontology references.
701    Maybe this could include a link to the physical quantity (etc, see for example the
702    <a href="http://physics.nist.gov/cuu/Units/introduction.html">NIST reference on SI</a>) to which the unit applies.
703    </p>
704    <p>
705    If this kind of link can be made, we could eventually attempt to impose a single unit to correspond to
706    all properties sharing a given <a href="http://physics.nist.gov/cuu/Units/introduction.html">quantity in the general sense</a>.
707    This may lead to very small or very large values, depending on the simulation, but at least allows simpler
708    interfaces.
709    </p>
710    <em class="todo">@@ THIS ISSUE NEEDS RESOLVING @@</em>
711    <h4><a name="sec5_3_7"/>5.3.7 Services</h4>
712    <p>
713    The goal of the SimDB specification is to define a protocol for querying interesting simulations
714    and related SimDB/Resource-s.
715  Once these have been identified the user should be able to access these simulations.  Once these have been identified the user should be able to access these simulations.
716    We assume that web services are the means to do so, and allow publishers to indicate such
717    web services as are available for a given Experiment. We assume for now that we know little of the
718    web service beyond some generic types: <i>download, cut-out, extraction, projection, custom</i>.
719    The SimDAP specification is being developed to address those aspects in detail.
720    We assume that there will be a base-URL implementing some standard DAL (VOSI?) like services
721    and leave it up to SimDB-client implementations to interact with these services in standard manners.
722    Only custom services can be directly accessed, and for now many services will necessarily be custom.
723    </p>
724    
725  <h2><a name="sec6"/>6 Physical models</h2>  <h2><a name="sec6"/>6 Physical models</h2>
726  Here we describe how we create physical models out of the logical model.  <p>
727    Here we describe how we create <i>physical models</i> out of the logical model.
728  A <i>physical model</i> is (see <em class="todo">@@TODO reference to some standard reference on data modelling@@</em>)  A <i>physical model</i> is (see <em class="todo">@@TODO reference to some standard reference on data modelling@@</em>)
729  a representation of the logical model that is adapted to a particular software environment.  a representation of the logical model that is adapted to a particular software environment.
730  The DM WG has mandated (IVOA interoperability meeting, Cambridge, UK, May 2003) that one  We present physical representations for the following contexts:
731  such representation should be an XML schema. This is to be used to define the structure of XML documents  <ul>
732  used in message to communicate instances of the SimDB Resource type.  <li>XML: we present an <a href="http://www.w3.org/XML/Schema">XML schema</a> defining valid XML documents</li>
733  Together with this we also create a relational database schema.  <li>Relational databases: we derive a relational database schema for storing instaces of the model.</li>
734  We propose this model as we want to use the ADQL standard under development in the VOQL WG  <li>Java: we present Java classes representing the
735  in the protocol for querying SimDB-s.  </ul>
736    We actually <i>derive</i> these representations from the logical model using transformation rules implemented in XSLT.
737    
738    we give pointers to the actual schema documents resulting from an implementation of such rules in XSLT.
739    In a similar manner we define rules and provide XSLT based implementations of these,
740    to derive a relational database schema from the logical model.
741    We propose this model as we want to use <a href="http://www.ivoa.net/Documents/latest/ADQL.html">ADQL</a>
742    in the protocol for querying SimDB-s. To this end we also produce first approximations to a <a href="">TAP
743    </p>
744    <p>
745    Our complete XSLT pipeline is described in more detail in <a href="#appB">Appendix B</a>.
746    It also produces an HTML document of the UML model in standardised form. The HTML document describes all
747    object types, value types and enumerations in detail. It also derives UTYPE-s for all features.
748    Once a more formal UTYPE definition is being worked out in the
749    The XSLT further produces Java classes which, using
750    <a href="http://java.sun.com/javaee/technologies/persistence.jsp">Java Persistence API (JPA)</a> and
751    <a href="http://java.sun.com/developer/technicalArticles/WebServices/jaxb/">Java Architecture for XML Binding (JAXB)</a>
752    annotations, provides simple means to store contents of SimDB/XML documents in
753    a SimDB relational database and retrieve them from there again.
754    </p>
755    
756  <h3><a name="sec6_1"/>6.1 Identifiers and References</h3>  <h3><a name="sec6_1"/>6.1 Identifiers and References</h3>
757    
# Line 697  Line 781 
781  </ul>  </ul>
782    
783  <h3><a name="sec6_3"/>6.3 XML Schema</h3>  <h3><a name="sec6_3"/>6.3 XML Schema</h3>
784    <p>
785    The DM WG has mandated (IVOA interoperability meeting, Cambridge, UK, May 2003) that one
786    such representation should be an XML schema.  
787    We foresee that this representation can be used to communicate instances of SimDB/Resource-s as XML documents.
788    Such communication can be for registering new SimDB/Resources in a SimDB, or
789    used in message to communicate instances of the SimDB Resource type.
790    Here we shortly describe rules how to derive an XML schema from our logical model and
791    </p>
792    
793  <h3><a name="sec6_4"/>6.4 UTYPE-s</h3>  <h3><a name="sec6_4"/>6.4 UTYPE-s</h3>
794  <p>  <p>
# Line 711  Line 803 
803  The <a href="#r_SpectrumDatamodel">Spectrum data model</a> was the first to add explicit  The <a href="#r_SpectrumDatamodel">Spectrum data model</a> was the first to add explicit
804  UTYPE-s for each of the attributes in its model and the <a href="#r_CharacterisationDM">Characterisaiton data model</a>  UTYPE-s for each of the attributes in its model and the <a href="#r_CharacterisationDM">Characterisaiton data model</a>
805  has followed that example. As long as the precise usage and relation of the syntax of the underlying data model is  has followed that example. As long as the precise usage and relation of the syntax of the underlying data model is
806  is not defined, we will follow these exmaples by assigning UTYPE-s explicitly to all elements in the model.  is not defined, we will follow these examples by assigning UTYPE-s explicitly to all elements in the model.
807  However, we will follow a fixed set of rules to makes this assignment and implement these in XSLT.  However, we will follow a fixed set of rules to makes this assignment and implement these in XSLT.
808  If a similar approach is at some time accepted within the IVOA, possibly in an alternative form, it will be straightforward  If a similar approach is at some time accepted within the IVOA, possibly in an alternative form, it will be straightforward
809  to adjust our definitions.  to adjust our definitions. The important point we want to make is that it is possible to simply define rules that then will
810    automatically produce the UTYPE-s for a given data model, i.e. the only discussion that is required is on the rules for doing so.
811  </p>  </p>
812  <p>  <p>
813  Our assumption is that the UTYPE should be able to uniquely represent any element in the data model, and in a manner  Our assumption is that the UTYPE should be able to uniquely represent any element in the data model, and in a manner
814  that is also easily interpreted. For now the elements that we assume need to be able to address are those that can be  that is also easily interpreted. For now we assume that we need to point to those elements
815  represented by a single value in a column. This leaves us to requiring to be able to derive UTYPE-s for the following  that can be stored in a column in a VOTable, i.e. for now we are looking for "simple" elements.
816  model elements:  We can use our relational mapping to identify all these features, they are
817  <ul>  <ul>
818  <li>Attribute</li>  <li> attributes (paying attention to attributes with non simple data types)</li>
819  <li>Reference</li>  <li> references (an identifier </li>
820  <li>Collection</li>  identifying the referenced object) and
821    <li>collections (through a pointer to the containing, parent object). </li>
822  </ul>  </ul>
823    VOTable also allows arrays to be stored in single columns, so a collection can be stored as an array of identifiers of
824    child objects. There are some other features that are not explicitly modelled, but are implied.
825    Examples are the identifier (ID) assigned to all objects and the name of the object type of an object.
826  </p>  </p>
827    <p>
828    Of course we could give each of the elements a uniquely generated identifier, but we assume that UTYPE-s should hold
829    semantic information, otherwise we could use the XMI-ids generated by the UML modelling tool.
830    To identify any of these elements uniquely within the context of the IVOA,
831    we then need the following components:
832    <ul>
833    <li>name of element (possibly a path expression for structured attributes leading to a "leaf attribute")</li>
834    <li>name of containing object type</li>
835    <li>a path expression for the package(s) containing the object type</li>
836    <li>unique identifier of the model, possibly its name if that is to be unique in the IVOA DM efforts</li>
837    <li>some indication of the context, unless this can be implicit.</li>
838    </ul>
839    NB this assumes that we do not have a uniqueness rule on the names of object types within a model, something we do actually
840    assume in the mapping of SimDB/RDB above. In that case we could leave out the package path.
841    </p>
842    <p>
843    One could argue one could also give nice, unique names to each of the elements, but to find out what the actual element in
844    the model and in other representations one would still need to perform a look up. Such a uniqe name would likely include some of
845    the elements above anyhow. So we believe it would be a waste of efforts to do so and instead propose a simple convention
846    for deriving the UTYPE-s form the model based on this hiherarchy.
847    We have done so using these rules (in BNF-like notation)
848    <dl>
849    <dt>attribute</dt>
850    <dd>
851    <pre>
852    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." &lt;attribute-name&gt; [ "." &lt;attribute-name&gt;]*
853    </pre>
854    </dd>
855    <dt>reference</dt>
856    <dd>
857    <pre>
858    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." &lt;reference-name&gt;
859    </pre>
860    </dd>
861    <dt>collection (as array of p0inters to child objects)</dt>
862    <dd>
863    <pre>
864    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." &lt;collection-name&gt;
865    </pre>
866    </dd>
867    <dt>container</dt>
868    <dd>
869    <pre>
870    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." "CONTAINER";
871    </pre>
872    </dd>
873    <dt>ID</dt>
874    <dd>
875    <pre>
876    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." "ID";
877    </pre>
878    </dd>
879    <dt>object type name</dt>
880    <dd>
881    <pre>
882    &lt;model-name&gt; ":" &lt;package-name&gt;[ "/" &lt;package-name&gt;]* "/" &lt;objecttype-name&gt; "." "DTYPE";
883    </pre>
884    </dd>
885    
886    </dl>
887    The HTML documentation generated from the logical model contains UTYPE-s for these features, generated according to these rules.
888    It will be obvious how to accommodate changes in the precise UTYPE specification, <em>as long as similar rules are upheld</em>.
889    </p>
890  <h3><a name="sec6_5"/>6.5 Java/JPA+JAXB (non normative)</h3>  <h3><a name="sec6_5"/>6.5 Java/JPA+JAXB (non normative)</h3>
891    
892  <h2><a name="sec7"/>7 Query Protocols</h2>  <h2><a name="sec7"/>7 Query Protocols</h2>
# Line 760  Line 917 
917  <em class="todo">@@ TODO Patrizia @@</em>  <em class="todo">@@ TODO Patrizia @@</em>
918  <h4><a name="sec8_1_4"/>8.1.4 USA</h4>  <h4><a name="sec8_1_4"/>8.1.4 USA</h4>
919  <em class="todo">@@ TODO Rick @@</em>  <em class="todo">@@ TODO Rick @@</em>
920    s
921  <h3><a name="sec8_2"/>8.2 Generating XML from simulation pipe lines</h3>  <h3><a name="sec8_2"/>8.2 Generating SimDB/XML documents from simulation pipe lines</h3>
922    
923  <h3><a name="sec8_3"/>8.3 SimDAP services</h3>  <h3><a name="sec8_3"/>8.3 SimDAP services</h3>
924    
# Line 769  Line 926 
926  Here we describe various aspects of UML modelling as we applied it to the current  Here we describe various aspects of UML modelling as we applied it to the current
927  problem area.  problem area.
928  <p>  <p>
929  UML allows communities to create a domain specific modelling language through its Profiling capabilitites  UML allows communities to create a domain specific modelling language through its Profiling capabilities
930  <em class="todo">@@ TODO is this the proper term ?@@</em>.  <em class="todo">@@ TODO is this the proper term ?@@</em>.
931    
932  We have an initial implementation of a UML profile as created by MagicDraw available under <a href="">this link</a>.  We have an initial implementation of a UML profile as created by MagicDraw available under
933    <a href="http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/input/IVOA%20UML%20Profile%20v-2.xml">this link</a>.
934  Here we list the main elements and give a a short motivation for their inclusion in the model/.  Here we list the main elements and give a a short motivation for their inclusion in the model/.
935  It is our opinion that the DM working group should be ultimately responsible for a profile such as this,  It is our opinion that the DM working group should be ultimately responsible for a profile such as this,
936  defining a domain specific language for all IVOA data modelling efforts.  defining a domain specific language for all IVOA data modelling efforts.
# Line 814  Line 972 
972  some of these are standard, some of these are domain specific extensions following  some of these are standard, some of these are domain specific extensions following
973  standard UML profile <i>stereotype</i> extension elements and associated <i>tag definition</i>.  standard UML profile <i>stereotype</i> extension elements and associated <i>tag definition</i>.
974    
975  <ul>  <dl>
976    <li>Model<br/>    <dt><a name="uml_model"/>Model (no visual counterpart)<dt>
977     (no visual counterpart)</li>    <dd>
978    <ul>    <ul>
979    <li> &lt;&lt;model&gt;&gt; </li>    <li> &lt;&lt;model&gt;&gt; </li>
980    <ul>    <ul>
# Line 824  Line 982 
982    <li>TagDefinition: title</li>    <li>TagDefinition: title</li>
983    </ul>    </ul>
984    </ul>    </ul>
985    <li> Package <br/><img src="img/package.jpg" />    </dd>
986      
987      <dt> Package <br/><img src="img/package.jpg" /></dt>
988      <dd>
989    <ul>    <ul>
990    <li>package containment</li>    <li>package containment</li>
991    <li>package dependency</li>    <li>package dependency</li>
992    </ul>    </ul>
993    </li>    </dd>
994    <li> Class <br/><img src="img/class.jpg" />    <dt> Class <br/><img src="img/class.jpg" /></dt>
995      <dd>
996    <ul>    <ul>
997    <li>isAbstract<br/>    <li>isAbstract<br/>
998      Indicated by <i>italicised</i> name of the object. Implies that no instances can be made of the class,
999      one needs sub classes for that.
1000    </li>    </li>
1001    </ul>    </ul>
1002    </li>    </dd>
1003    <li> DataType <br/><img src="img/datatype.jpg" /></li>    <dt> DataType <br/><img src="img/datatype.jpg" /></dt>
1004    <li> Enumeration <br/><img src="img/enumeration.jpg" /></li>    <dd></dd>
1005    <li> Property: attribute<br/><img src="img/attribute.jpg" /></li>    <dt> Enumeration <br/><img src="img/enumeration.jpg" /></dt>
1006      <dd></dd>
1007      <dt> Property: attribute<br/><img src="img/attribute.jpg" /></dt>
1008      <dd>
1009    <ul><li>&lt;&lt;attribute&gt;&gt; </li>    <ul><li>&lt;&lt;attribute&gt;&gt; </li>
1010    <ul>    <ul>
1011    <li>TagDefinition: minLength<br/>    <li>TagDefinition: minLength<br/>
# Line 846  Line 1013 
1013    <li>TagDefinition: maxLength<br/>    <li>TagDefinition: maxLength<br/>
1014    </li>    </li>
1015    </ul>    </ul>
1016    <li> &lt;&lt;ontologyterm&gt;&gt; </li>    <li> &lt;&lt;ontologyterm&gt;&gt; <br/>
1017      There are many instances in the data model where we need to describe elements of the
1018    SimDB/Resource-s explicitly, because we do not have implicit information based on the context.
1019    Examples are the various properties of object types, the target objects and processes etc.
1020    Apart from a name and a description we then frequently add
1021    an attribute which is supposed to "label" the element according to an assumed standard list of terms.
1022    We model this using the <pre>&lt;&lt;ontologyterm&gt;&gt;</pre> stereotype. Attributes with this stereotype
1023    are assumed to take their values form such a predefined "ontology".
1024      </li>
1025    <ul>    <ul>
1026    <li>TagDefinition: ontology<br/>    <li>TagDefinition: ontologyURI<br/>
1027    A URL locating a standard (RDF|SKOS|OWL|???) document containing    A URL locating a standard (RDF|SKOS|OWL|???) document containing
1028    a list of terms from which the value for this attribute may be obtained.    a list of terms from which the value for this attribute may be obtained.
1029    It is our opinion that the Semantics working group should be responsible for the    It is our opinion that the Semantics working group should be responsible for the
# Line 858  Line 1033 
1033    </li>    </li>
1034    </ul>    </ul>
1035    </ul>    </ul>
1036    <li>Inheritance    </dd>
1037    <br/><img src="img/inheritance.jpg" /></li>    <dt>Inheritance
1038    <li>Binary association end: collection    <br/><img src="img/inheritance.jpg" /></dt>
1039    <br/><img src="img/collection.jpg" /></li>    <dd>
1040    <li>Binary association end: reference    Indicates the typical <i>is a</i> relation between the sub-class and its base-class (the one pointed at).
1041    <br/><img src="img/reference.jpg" /></li>    In this profile we do not support multiple inheritance. <em class="todo">@@ TODO explain? @@</em>.
1042    <li>Binary association end: subsets    </dd>
1043    <br/><img src="img/subsets.jpg" /></li>    <dt>Binary association end: collection
1044      <br/><img src="img/collection.jpg" /></dt>
1045      <dd>
1046      This relation indicates a <i>composition</i> relation between one, parent object and 0 or more child objects.
1047      The life cycles of the child objects are governed by that of the parent.
1048      </dd>
1049      <dt>Binary association end: reference
1050      <br/><img src="img/reference.jpg" /></dt>
1051      <dd>
1052      This is a relation that indicates a kind of <i>usage</i>, or <i>dependency</i> of one object on another.
1053      It is in general shared, i.e. many objects may reference a single other object. Accordingly the referenced
1054      object is independent of the "referee". In our model the cardinality can not be &gt; 1.
1055      </dd>
1056      <dt>Binary association end: subsets
1057      <br/><img src="img/subsets.jpg" /></dt>
1058      <dd>
1059      This indicates that a relation overrides a relation defined on a base class.
1060      It does so by specifying that the class at the end point of the relation should be a subclass of the
1061      class at the enpoint of the original, subsetted relation.
1062      </dd>
1063            
 </ul>  
1064    
1065  </p>  </p>
1066    
# Line 875  Line 1068 
1068  <h2><a name="appB"/>Appendix B: XSLT pipe line</h2>  <h2><a name="appB"/>Appendix B: XSLT pipe line</h2>
1069  <em class="todo">@@ TODO Laurent @@</em>  <em class="todo">@@ TODO Laurent @@</em>
1070    
1071  <h2><name="glossary"/>Glossary and Acronyms</h2>  <h2><a name="glossary"/>Glossary and Acronyms</h2>
1072  <dl>  <dl>
1073  <dt><a name="g_SimDB">SimDB</a></dt>  <dt><a name="g_SimDB">SimDB</a></dt>
1074  <dd></dd>  <dd>Acronym for <i>Simulation Database</i>, the standard that we propose to define in this Note.
1075    Implementations of SimDB offer a query interface for discovering simulations (and related entities)
1076    using ADQL, based on a prescribed (i.e.normative) relational data model and for describing simulations
1077    via XML documents following prescribed XML (i.e. normative) schema.</dd>
1078  <dt><a name="g_SimDAP"/>SimDAP</dt>  <dt><a name="g_SimDAP"/>SimDAP</dt>
1079  <dd></dd>  <dd>Acronym for <i>Simulation Data Access Protocol</i>, a related standard to SimDB,
1080    which will define services for accessing simulations discovered using SimDB.</dd>
1081  <dt><a name="g_SimDB/DM"/>SimDB/DM</dt>  <dt><a name="g_SimDB/DM"/>SimDB/DM</dt>
1082  <dd>The logical data model defining the structure of <a href="#g_SimDB">SimDB</a>.</dd>  <dd>The logical data model defining the structure of <a href="#g_SimDB">SimDB</a>.</dd>
1083  <dt><a name="g_SimDB/RDB"/>SimDB/RDB</dt>  <dt><a name="g_SimDB/RDB"/>SimDB/RDB</dt>
1084  <dd>The representation of the SimDB/DM as a relational data base schema.</dd>  <dd>The representation of the SimDB/DM as a relational data base schema.
1085    This implies a parti</dd>
1086    <dt><a name="g_SimDB/RDB"/>SimDB/Views</dt>
1087    <dd>The representation of the SimDB/DM as a collection of database view definitions. Each View directly represents
1088    a complete DM class as a relational table, this in contrast to the underlying SimDB/RDB representation in tables,
1089    at least in the JOINED object-relational mapping strategy.</dd>
1090  <dt><a name="g_SimDB/XML"/>SimDB/XML</dt>  <dt><a name="g_SimDB/XML"/>SimDB/XML</dt>
1091  <dd>The XML representation of the SimDB/DM</dd>  <dd>The XML representation of the SimDB/DM</dd>
1092  <dt><a name="g_SimDB_resource"/>SimDB resource</dt>  <dt><a name="g_SimDB/Resource"/>SimDB/Resource</dt>
1093  <dd>A top-level data product stored in a SimDB.  <dd>A top-level data product stored in a SimDB.
1094  A SimDB resource can be described in a SimDB/XML document, but none of its constitutents can.</dd>  A SimDB/Resource can be described in a SimDB/XML document, but none of its constituents can.</dd>
1095    <dt><a name="g_SimDB/TAP"/>SimDB/TAP</dt>
1096    <dd>The TAP(-like) metadata representation of the SimDB/DM.
1097    This is currently (May 2008 <em class="todo">@@ TODO update once the TAP specification is out @@</em>
1098    a representation of the <a href="#g_SimDB/Views">SimDB/Views</a> as a VOTable document.
1099    </dd>
1100  </dl>  </dl>
1101    
1102  <h2><a name="references">References</a></h2>  <h2><a name="references">References</a></h2>

Legend:
Removed from v.452  
changed lines
  Added in v.453

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