LTER_core-metabase is a relational database model (Postgres), based on the GCE LTER Metabase, with adaptations by UCSB LTER sites. The “core” part of the name has two meanings: (1) A shared base of code designed to avoid divergence of versions at LTER sites and (2) the part of the original Metabase which pertains to EML metadata.
Interactive visualization using schemaSpy: (temporary page) (To build your own view of the database, try SchemaSpy.)
ORCIDs go in the ListPeopleID table. The IdentificationSystem is ORCID
and the IdentificationURL is the ORCID, e.g., https://orcid.org/0000-0002-1940-4158
.
See also populate.
When describing a new version of a dataset for which a previous version was already described in the database, you overwrite existing values with updated values. In other words, you only store the metadata for the updated/new version. You won’t be able to generate EML for the old data and old metadata (unless you change everything back to the old version in your database tables).
Other data types, such as R scripts or netCDF files, are recorded in the DataSetEntities table with an EntityType value of otherEntity
.
The current system is only designed to describe the most recent version of the dataset. Values in tables describing a given dataset are overwritten as needed for a new version of the dataset. If recording provenance is desired, you can author revision notes in the maintenance_changehistory table in the pkg_mgmt schema.
DataSetSites can store rectangles in geographic coordinates or points, but not polygons of arbitrary shape. If required, you can archive a shapefile or other geospatial dataset with your data tables and mark it with an EntityType value of otherEntity
.
New tables and columns to support EML2.2 are already being added but as of Version1.0, metabase does not yet support all the new features. (Sneak preview: a schema for semantic_annotation is submitted and in review by our own in house expert, aka MOB.)