Difference: GerardLemson_SimDB_Notes (2 vs. 3)

DM

• SimDB in UML, ok?
• SimDB in XMI, ok?
  • UML follows a profile, is the profile ok?
  • Profile is mapped to interemediate XML representation (following schema!), is that a good idea?
• UML is documented usin an HTML document, with a particular format. Is that OK?
• The logic behind the SimDB model (SimDB/DM) will be written up in a Note. Together with HTML, will that be sufficient for reuse by others (e.g. SimDAP, S3)?
• We define UTYPEs for all elements in the model (see the HTML doc). We follow a particular syntax, is that ok? [NB use of a "/" as package/package and package/class separator can be easily changed to a "."]
• We subdivide the model in packages (ala namespaces in XML) to demarcate common definitions in the model and relations between (groups of) these. Is that ok?
• We require externally defined semantic (SKOS?) vocabularies. These define lists of valid values that certain special types of attributes MUST (SHOULD?) be chosen from. Some of these already exists, others must still be defined. Is that ok? NB there is a TIG effort underway to define new lists targeted to simulations.
• We provide a representation (mapping) of the data model to XML schemas. We follow a particular set of rules. Are the particular rules we use ok? [TBD link to "rules" in Note]
• We provide a representation (mapping) of the data model to relational database schemas. We follow a particular set of object relational mapping rules. Are the particular rules we use ok? [TBD link to "rules" in Note]
• Is the use of the data model as a data model for a database ok?
• We have a normalised model and a proposal for a denormalised version of it (can be completely derived using XSLT both forward and beckward). Can we specify them together as a single model, or should they be separate specs?
• The approach using a hierarchy of models: conceptual(or analysis/domain)-logical-physical, is that ok? See Wikepedia entry

Approach

• We build this spec around a data model describing simulations, i.e. a meta-data model.
• We start with an abstract, application independent model (domain momdel or analysis model)
  • Following "standard" modelling apporaches: analysis -> logical -> physical
• MAYBE we derive from the domain model a separate applicationd dependent, logical model (currently logical and domain model are the same)
• SimDB/DM is designed in UML
  • UML is stored in XMI
  • Model is drawn using MagicDraw Community Edition 12.1 and stored in its XMI format
  • We follow a predefined UML profile
  • The particular profile can be found here
    • ALso in appendix to the Note
  • Profile is mapped to "intermediate representation", XML schema file intermediateModel.xsd
  • UML aims to be comprehensive, i.e. contains all documentation etc.
• We use the (intermediate representation of the) (logical) model to derive physical representations that can be used in implementations:
  • A relational schema, basis for a specialised TAP protocol
    • we use object-relational mapping rules (implemented in an XSLT script) to derive the relational schema directly from the UML
    • ISSUES
      • treatment of inheritance hierarchies
  • An XML schema (actually a set of XML schema documents), defining valaid SimDB/XML documents
    • We use mapping rules to derive the XML schema directly from the UML. rules similar to those used in registry/VOTable schemas.
    • ISSUES
      • Mapping references.
  • an [[][HTML document]], for human consumption
  • a list of UTYPEs, to be used for example in VOTable results of ADQL queries to SimDB/TAP
    • we use rules to derive the UTYPEs directly from the UML
    • the UTYPEs are defined in the HTML document

Contents of model.

• Model in http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/specification/uml/SimDB_DM.xml
• Use of packages: simdb, protocol, experiment, object, dal
• Anchored in Resource, base class of Experiment_(_Simulation,_PostProcessing_), Protocol (Simulator,_PostProcessor_), Project, WebService
  • NB to Registry+DM: SimDB/Resource similar to, but not identical with Resource Model's Resource. Some of them (Protocol, Project, WebService, some Experiments) could be Registry/Resources as well. We propose to create particular representations of these in terms of the Resource data model.
• We use a WebService class as generalisation to accessURL in standard DAL protocols, to implement the issue that on the one hand many results are too large to download simply and 2) we want to support all interesting custom services as well as standardised ones such as SimDAP.
• We allow a kind of characterisation of results. We use here the proposed Characterisation domain model as presented for example in this presentation.
• We use in several places special attributes that SHOULD (MUST?) take values in a shared semantic vocabulary of terms.

Usage of model

• Model is heavily normalised, hence the possible need for a ­_denormalized_ version of the model (e.g. http://volute.googlecode.com/svn/trunk/projects/theory/snapdm/specification/uml/SimDB_DM_denormalised.xml)
  • NB to DM: IF we produce a logical model separate from the domain model, how should we treat this? 2 separate models, 1 model? How do we relate one to the other? UTYPE as part of profile? (that is current proposal here).

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->