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

[David_Brooks]

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.

[Anonymous User]

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?).

[JonathanDandois]

This is really interesting, so is the idea here that you would have a new separate field in each feature class called "Metadata" that is a large text field (1000 char, whatever) within which you would then add and maintain a standardized string of documentation about each feature? What would the content look like?  Would it be the same data for each feature and all features have their "Metadata" field updated at the same time whenever the Metadata needs to be updated? Or is it metadata per row, that seems like it would be exhausting.

[Anonymous User]

I don't think OP or I were suggesting this. That's just as impractical as the current metadata documentation.

In our case, we used domain coded values to describe datum information like:

datum: WGS84

realization: (G1762)

epoch: 2019.234

vert_datum: EGM96

source: GNSS

...etc

This approach forces these values to be populated or explicitly demonstrate that they are unknown.

This is a good technique for this type of critical positional information, because otherwise:
- It doesn't get recorded

- It's hidden in traditional metadata and the user is unaware

- It get stripped when moving between systems (as OP described)

It's probably not a good candidate for all types of information - I was just describing our own use case here.

Anything that you really want to persist and can be field calculated (assigned) is worth checking out in my opinion.

[David_Brooks]

@Anonymous User @JonathanDandois Im glad this topic has a bit of interest, as I feel it's a hugely overlooked part of day to day GIS management.

Right now, we are storing all our metadata in the Summary and Description metadata fields. I had started storing this information also in attribute table fields, and had this text auto-populate as default values, but as you say @JonathanDandois this has been rather exhausting. 

On further inspection, I can see that the description field does make it through to a rest service when published to enterprise in a Map Service, but to get all the metadata fields, you'd need to be publishing individual feature services, which isn't always achievable or desirable. Further to that, the Description field is "rich text" rather than "plain text" so you end up with a bunch of HTML tags cluttering up the description in the rest endpoint.