meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
tml_infrastructure [2021/10/15 04:13] – gregbalcotml_infrastructure [2021/10/23 03:41] (current) – gregbalco
Line 1: Line 1:
 ===== Transparent Middle Layer (TML) data management infrastructure ===== ===== Transparent Middle Layer (TML) data management infrastructure =====
  
-The ICE-D project is an attempt to implement a so-called 'transparent middle layer' data management and software infrastructure for cosmogenic-nuclide data. +The ICE-D project is an attempt to implement a so-called 'transparent middle layer' data management and software infrastructure for cosmogenic-nuclide data. If the problem is that it's hard to do synoptic analysis of a data set that is changing all the time as middle-layer calculations evolve, our idea is that the solution has the following elements:
  
-Insert some stuff from the proposal here+A data layer: a single source of observational data that can be publicly viewed and evaluated, is up to date, is program- matically accessible to a wide variety of software using a standard application program interface (API), and is generally agreed upon to be a fairly complete and accurate record of past studies and publications, beneath:
  
-Link to the paper about this here+A transparent middle layer that calculates geologically useful results, in this case exposure ages, from observational data using an up-to-date calculation method or methods, and serves these results via a simple API to:
  
-Also link to proposal+An analysis layer, which could be any Earth science application that needs the complete data set of exposure ages for analysis, visualization, or interpretation. 
 + 
 +The middle layer is "transparent" just because the calculations are fast enough that the user doesn't notice them as a significant obstacle to analysis or visualization. Overall, the important property of this structure is that only observational data (which do not become obsolete) are stored. Derived data (which become obsolete as soon as the middle-layer calculations are improved) are not stored, but instead calculated dynamically when requested by an analysis application. This eliminates unnecessary effort and the associated lock-in effect created by manual calculations by individual users, and allows continual assimilation of new data or methods into both the data layer and middle layer without creating additional overhead at the level of the analysis application. Potentially, this structure also removes the necessity for redundant data compilation by individual researchers by decoupling agreed-upon observational data (which are the same no matter the opinions or goals of the individual researcher and therefore can be incorporated into a single shared compilation) from calculations or analyses based on those data (which require judgements and decisions on the part of researchers, and therefore would not typically be agreed upon by all users).  
 + 
 +The reason the writing style just changed abruptly there is that much of the above paragraph is copied from [[https://gchron.copernicus.org/articles/2/169/2020/|this paper]].  
 + 
 +For the special case of cosmogenic-nuclide geochemistry, the general concept is explained (sort of) in this figure from the paper: 
 + 
 +{{ :figure_1_layers.png?600 }} 
 + 
 +And what that actually translates to in terms of computational infrastructure is explained in this other figure: 
 + 
 +{{ :figure_2_spaghetti.png?600 }} 
 + 
 +If that figure didn't make total sense immediately, here is a more straightforward explanation:
  
 === Data Layer === === Data Layer ===