Is anyone maintaining a metadata standard in the attribute table instead?

06-27-2022 02:40 AM
MVP Regular Contributor

We're just about to scope out a new metadata standard for our client. I have always been a critic of the GIS metadata format, for one reason, and one reason only. Metadata DOES NOT AUTOMATICALLY PERSIST THROUGHOUT THE STACK. It breaks at every single level, without pythonic intervention.

You can have classic metadata for; a) individual layers, b) map services, c) web maps, d) web apps, and at each level, you need to repopulate the item name, description, summary and tags, all of which will require additional administrative overhead.

Ultimately, if a Portal user wants to know the origin of an individual layer within a web service, they either need to hope that the data owner has excellent stadards (and time), and populates metadata at every enterprise tier themselves, or that they have individual services for individual layers, thus ensuring fidelity of metadata from feature class through to web app.

THEREFORE, we're considering scrapping  the manual inputting of metadata within the usual Summary, Description, Tags, sections, and just storing it in the attribute table for all feature classes. So a new data attribute schema will also contain the metadata standard. 

The advantage of this, is that metadata is accessible throughout the entire stack just by inspecting attribute information. In addition, metadata for web maps and web services could be built up pythonically. (the web services would then amalgamate metadata from the indiviual layers, with tags and categories being built up from thematic fields within the data.

We would be really interested to see if this has been implemented elsewhere, or whether there are in fact better mandraulic approaches to the metadata problem, that utilises the existing metadata functionality within the Enterprise.

..Maps with no limits..
1 Reply
Occasional Contributor III

I've had some success with this approach for domain coded values. Specifically for coordinate information, where the data originated from, original datum/realization, etc. It has the advantage of evangelizing the importance of different fields and forcing completeness at the same time. 

I really, really wish there was Git for geospatial (g4g?).