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
