Finding, dating and settling down with the perfect mate is a lot easier with online dating tools. When you look for a potential match, maybe you only want a few details - like name and a list of interests. But as things get serious, you want to know more.
In the real and online world, you have lots of ways to learn more. But in the online data dating world, you really only have one - metadata.
And, well, our metadata makes it hard to commit…So we’re updating it.
Metadata Dream Date
In my metadata dreamworld:
- Each required field would have a thoughtful and robust justification
- Fields would be easy to complete and populate (think drop downs and controlled vocabulary)
- The metadata would be in a friendly, portable file (think json)
- Our Socrata platform would include an automated dataset of datasets that included each metadata field for each dataset. And I would make charts and views of the dataset of datasets that summarized and tracked our performance in open data.
- Bonus feature! An API on the dataset of datasets that would let us create apps or feeds for recently updated, new datasets, etc!
Our metadata (the data about our datasets) is more or less out of the box (see an example for business registered in SF). We have a handful of custom fields like Department and frequency, but we haven’t sat down and really thought through what fields we should include (and require) and why. And we’re inspired by metadata leadership from Open New York and Albuquerque.
How we’re tackling metadata in San Francisco</h2>
We’ve kicked off a working group to draft a metadata standard. The team includes some metadata experts, library scientists, and some of our biggest publishers on DataSF. Read our project document with background/motivation/major steps.
But before we kicked off the group, we surveyed the metadata landscape for existing practices. Some major findings:
- Alot of great work has been done in migrating existing frameworks to accommodate open data (Dublin Core, DCAT, and Common Core). Though we were surprised by some interesting gaps (e.g. data quality notes, field definitions).
- A balance is to be had in terms of making something required if a) you want compliance and b) you want to get data published. Alot of portals have metadata requirements, but compliance can by tricky.
Read our full document on Metadata: Existing Practices and Survey.
(And PS - you can always visit our Resources page for all of our metadata documents.)
Your Metadata Dream Date
And we want to hear from you: - Data publishers - What works and what doesn’t about metadata? - Data users - What elements and fields are essential? - What’s field elements are hard to do? Can we crowd source data dictionaries???
Drop us a line at datasf at sfgov dot org or check out our standard and give us feedback: