Reply by Peter Schweitzer on 4 Feb 2002:
First some questions: Why do you ask? Do you want or need to pass data to someone else? If so, what do they need to know? How valuable are the data--how long did they take to create, and how long will it take the next person to re-create the data when you leave your current job? I'm not being facetious here--some data don't need to be documented because it's too easy to build them from scratch. Graticules fit in this category. You also don't need to make metadata for data that you got from a well- known source and you didn't alter. So don't make metadata for USGS DLG data unless USGS is paying you to do that.
The problem with telling the GIS to make the metadata for you is that the GIS doesn't know much about the data, and what it does know is mostly unimportant. It knows the number of points, lines, and polys you have. It might know the coordinate system, if you've told it. It knows the labels of the attributes and the type of variable in which it stores their values. But it doesn't know what those labels mean, it doesn't know the units of any numerical attribute values, and it doesn't know what any categories or abbreviations mean, even if they're "standard practice" in your field. It might know the directory in which you've stored the data, and it might know the name of the file. But it doesn't know what any of that means. You get the picture, I hope.
A few years ago I wrote an article and a set of web pages called Metadata in Plain Language. My purpose was to get away from the purely technical jargon of the Standard and cut to the chase about what we really need to document and how. This resource might give you some perspective, at least to help you decide what metadata elements are most important for your users. It's at
https://geology.usgs.gov/tools/metadata/tools/doc/ctc/
One way to start would be to take the first page of those questions and simply type answers to them. Follow the links to get more specific information. After you've answered the questions well, you'll have most of what you need to create good documentation. I suspect the encoding process is not going to be as hard as gathering the info and articulating it well.
Don't use document.aml. It does so many things wrong that you'll end up spending more time fixing than writing. ArcCatalog will give you a start, and will gather the "properties" that the GIS knows. On Unix the best editor for metadata is probably Tkme, but you might need to arrange with your system administrator to have it set up properly. Xtme works but has fewer helpful features. Even vi will do, but you'll find it easier if the editor knows how to spell the field names and knows which fields go where.
FGDCMETA.aml is a helpful aid for Unix ArcInfo users. This script culls some information from the coverage and puts it into a metadata record, launching an editor for you to add the rest. But it's only designed to facilitate, and like ArcCatalog, it only knows what you've told the GIS about your data.
I know it can be a bit bewildering at first. I believe the best solution is to first focus on understanding what your users will need to know, recognizing that they may not have the same background and experience that you do. Armed with this perspective, you can begin to explore the tools and techniques that many others have been using.
Good luck. Feel free to contact me if I can provide additional information or assistance.