I have been doing some work developing metadata records and automated processes for generating and updating metadata as part of data refresh and ETL processes lately. In the course of doing this, we are trying to develop means of providing very rich and well-documented, FGDC and Agency-profile metadata.
However, when it comes to attributes... Seems FGDC and ESRI both have put some disincentives in the way of capturing attribute data and documenting them painlessly.
http://www.fgdc.gov/metadata/csdgm/05.html
One could take the easy way out, and just put in an overview description and citation, and completely ignore any detailed description of the individual attributes.
Or, one could use ArcCatalog and extract a quick listing of attributes as <attr> elements - but.... ArcCatalog only captures and stores the <attrlabl> elements within this. In the infinite wisdom of the folks at FGDC and the folks that developed MetaParser, they then further require attribute domain <attrdomv> (and in my experience, 99.99% of most attribute data is either never validated against a domain, or validated outside of the GIS system, in the database, data capture or ETL process) and attribute value accuracy description <attrvai><attrvae> which I agree is valuable where applicable, but in many instances is not applicable, such as feature name, FID or other types of fields.
It tends to make providing detailed attribute information a disincentive, and steers folks toward taking the cop-out approach of just providing the overview description. Seems like an opportunity lost.
However, when it comes to attributes... Seems FGDC and ESRI both have put some disincentives in the way of capturing attribute data and documenting them painlessly.
http://www.fgdc.gov/metadata/csdgm/05.html
One could take the easy way out, and just put in an overview description and citation, and completely ignore any detailed description of the individual attributes.
Or, one could use ArcCatalog and extract a quick listing of attributes as <attr> elements - but.... ArcCatalog only captures and stores the <attrlabl> elements within this. In the infinite wisdom of the folks at FGDC and the folks that developed MetaParser, they then further require attribute domain <attrdomv> (and in my experience, 99.99% of most attribute data is either never validated against a domain, or validated outside of the GIS system, in the database, data capture or ETL process) and attribute value accuracy description <attrvai><attrvae> which I agree is valuable where applicable, but in many instances is not applicable, such as feature name, FID or other types of fields.
It tends to make providing detailed attribute information a disincentive, and steers folks toward taking the cop-out approach of just providing the overview description. Seems like an opportunity lost.
Posts
I stumbled on your interesting blog while looking for more information about the MAPPS case.
I wanted to note that ESRI has taken some steps towards dealing with attrdomv and attrvai/attrvae with the use of the measurement tables in data models. What this essentially means is that detailed attribute information is only appropriate for instrument collected data (which would make sense), but is then inherently stored in the geodatabase through the measurement parameters tables. Generating the metadata then just consists of accessing the parameters table and stored domains. Since validation rules are part of the data model implementation, domain checking and accuracy descriptions are all part of the geodatabase schema.