Is there an existing, standard, universal approach (and hopefully existing tools that support managing it) for storing geospatial metadata in non-ESRI spatial databases alongside (and therefore able to travel with when dumped) the data themselves.
I'm hoping to identify an approach that simply relies on tables and relations and could therefore be used in databases like PostGIS, Spatialite, Oracle, SQL Server, etc. Here, metadata mean the narrative information about the data (i.e., US FGDC or ISO 19139 geospatial metadata type information) - not the BBOX and internal stuff.
ESRI users have the now several XML formats that can universally describe and accompany data whether they be files (Shapefiles) or Geodatabases. However, what existing options exist when ESRI software are not used? Yes, of course, I could design my own tables, data structure, etc. But why reinvent a wheel that must surely exist.
UPDATE:
Complex architectural components like Geonetwork (or anything necessarily involving a server) is exactly what I need to avoid. Also, the metadata would live with the data, not as a separate database. Requirements are below and I should have stated it at the start.
System requirements: 1. Architecture must need nothing more than QGIS and a Spatialite Database - partly because the organization is not sophisticated enough to run anything on a server and doesn't have money to buy anything or have anything built/deployed.
Functional requirement: 1. The data must be easily distributed to many people and the documentation must not be easily separated from the data - meaning they should live and easily be distributed together so that I always know what the data are and why they were created, etc - if I have the data I have the documentation. 2. Like the data themselves, the metadata documentation should be easily editable and maintained using intuitive desktop tools, and by non-technical staff.
Use case: 1. Bobby the Student Volunteer (and just learning GIS) creates some data of monitoring sites as part of a study. 2. Bobby records the inputs he used, explanation of his processing steps, and other info that helps others to understand the lineage of the data. 3. Bobby gets a real job and leaves, leaving his data backed up on CD-ROM. 4. Two years later someone finds the data and determines it to be very useful because they can read the documentation that are within the data.
If you come from sophisticated organizations you'd say, "Man, what a screwed up situation. Just manage the data the Right Way (whatever that is)." But related scenarios are actually quite common in my world.
