UGRC MATT - next steps

[nathankota]

UGRC data stewardship - Metadata and Asset Tracking Tool (MATT)

Benefit

Build on the progress of the website rebuild and new SGID index sheet and start connecting the flow of data and metadata with the existing UGRC internal process tools (e.g. Sweeper, Porter, and so forth) and identifying how to achieve synchronization across the distributed SGID platform(s).

Acceptance Criteria

• Start connecting the flow of data and metadata with the existing UGRC internal process tools (e.g. Sweeper, Auditor, Porter, Cambiador, Supervisor, and so forth) and identifying gaps where other tools, processes, considerations are needed.
• Identify data (tables, schemas) gaps for managing SGID integration
• Create a diagram of the process and potential effects of changing, introducing, and removing SGID data; data connections and flow; identifying where existing UGRC tools fit in and the need for other tools, processes, and so forth.

Notes

Over time, the existing sheet used by UGRC staff to inform our SGID data update process has become outdated and no longer suits the intricacies of the actual data update lifecycle. We need a more advanced and robust system to manage all aspects of the lifecycle of SGID data sets. Ultimately, we seek to create a centralized, single source of truth place and associated processes for SGID metadata (both UGRC and data layer) to be captured, managed, and distributed to all necessary SGID access points, whether the UGRC website, AGOL/open data, Open SGID, internal database, and so forth. A more fully integrated data stewardship process to merge all the existing disparate parts of SGID and data management. Having a single source of truth is an ideal goal so that all facets of the SGID (agol, open sgid, etc.) are updated and operating from the same data.

Components, considerations, and questions around the MATT are:

• SGID data lifecycle
• stewardship database
• sgid index
• new website
• sgid rating system
• multi-user editing (portal/enterprise and branch versioning)
• metadata
• what lives in Internal and what do we point to?
• roads update process v2 (attribute rules, portal, etc)
• (maybe the API?)

A related conversation about SGID data lifecycle related to FEMA floodplain data that used to be aggregated and organized by UGS and sent to UGRC for inclusion in the SGID:

How do we proceed with making this data discoverable via the open sgid and open data? Where is the line in the sand on what we make available in our ‘hosted’ data and to what we point folks to? We need to define that line in the sand. Is used in the API? Is it used in basemaps? Idea: use the api to suggest what should be hosted in the sgid. The data pages analytics? How does the sgid index play into this Making sure it remains a curated list Maybe this becomes a part of the PI Planning. The bigger picture of how we proceed with the next version of the data lifecycle… sgid rating system, sgid index db, etc…

Risks

• Time among other duties
• Meeting schedules
• Agreement among peers about direction/vision

Issue References

refs #21

[gregbunce]

parking this thought here for now: the MATT we need to also document the origin and justification for all data entering the SGID. aka: the backstory. this info needs to go beyond who the agency steward is. Currently, we have data in the SGID that we no longer have the story on because the folks who were originally involved no longer work here or have retired.

[gregbunce]

we should be capturing dataset dependencies, too. (address points > NG911, NAD, etc.)