-
Notifications
You must be signed in to change notification settings - Fork 4
Metabase history
GCE metabase | SBC, MCR metabase | SBC MBON data packages | SBC LTER data packages | |
---|---|---|---|---|
Uses |
|
|
|
|
Features |
|
|
|
|
Activities |
2011
|
2015
|
2017
|
Gastil-Buhl, M. and M. O'Brien. 2013. Data Package Inventory Tracking: Slicing and Dicing with SQL. LTER Spring 2013 Databits.
Kui Li. 2018. Postgres, EML and R in a data management workflow EDI webinar
Kui Li and M. O’Brien. 2018. Postgres, EML and R in a data management workflow. LTER Spring 2018 Databits.
O'Brien M. and M. Gastil-Buhl. 2013. Metabase Adoption by SBC and MCR LTER Spring 2013 Databits.
O'Brien, M. 2011. The Santa Barbara Coastal (SBC) LTER's implementation of projectDB using Metabase LTER Fall 2011 Databits.
Sheldon, W.M. Jr., J. F. Chamblee, and R. Cary. 2012. Poster: GCE Data Toolbox and Metabase: A sensor-to-synthesis software pipeline for LTER data management. 2012 LTER All Scientists Meeting, 11-Sep-2012, Estes Park, Colorado.
Sheldon W. and J. Carpenter, 2010. Implementing ProjectDB at the Georgia Coastal Ecosystems. LTER Fall 2010 Databits.
Code to read from SBC or MCR metabase, create EML records: https://github.com/mobb/MB2EML
Code for SBC metabase maintenance (incomplete): https://github.com/mobb/MBmaint
UCSB LTER metabase (2013, by SBC and MCR LTER): tbd
created and used by Santa Barbara Channel MBON (SBC MBON): tbd
SBC LTER modifications: tbd
LTER-core-metabase isn't a pure subset of Metabase. It combines separate Metabase tables into a single table in some cases, and opts for a single field like instrumentDescription instead of separate tables for instrument model information and calibration and parameters for example. Another example: Metabase allows you to describe individual method steps in a separate table, whereas LTER-core-metabase relies on an external Word document in which you could outline individual method steps if you wanted. LTER-core-metabase is intended to accommodate basic dataset description needs with a focus on supporting EML generation and leaves other content to be handled by a given site or project.
Metabase supports these broad categories of information while LTER-core-metabase does not (at least not directly):
- Projects, like a DNA sampling project that happened for a few years under your LTER
- Links to species
- Links to publications
- Supplemental info, like data anomalies, materials, dataset usage notes, general comments
- Demographic info for personnel. This was included in Metabase for NSF reporting; however, now that NSF emails project personnel directly to ask for this information, it is not as critical to store demographic details in the database.
- Supervisor and committee member details for personnel
- NSF-funded project list for personnel
- Polygons to represent geographic areas
- More detail on geographic descriptions, like site history, hydrography, geology, etc., and site coordinates in decimal degrees, DMS, and UTM coordinates
- Website supporting materials like web map identifiers, map filenames and formats, personnel profile pages, links to profile pictures
These sorts of features (e.g., as in original GCE Metabase) can be added to LTER-core-metabase as extensions. Best practice is to explore what has been done already in your community, and look for ways to adopt common solutions. See the full documentation and issues list for suggested features.