3 ms·

I sort of applaud the goals of projects like this, but I feel sorry for anybody who has to be compliant with them. I'm involved with a data collection and arch

I sort of applaud the goals of projects like this, but I feel sorry for anybody who has to be compliant with them. I'm involved with a data collection and archiving project right now. Occasionally I'll get distracted with ideas like "Maybe I should make it compliant with Dublin Core/OWL/DCAT/WhateverTripleFlavorOfTheMonth" and then I go down a rabbit hole of meta(meta(meta)) documents like this for two hours and come back feeling like I know less than when I started. So I just make up some JSON thing that seems like it will probably make intuitive sense in 100 years, write programs to generate and read that, and get on with my day. I'd love for there to be some kind of "get to the point" document (complete with examples!) that didn't require reading 10,000 pages of bureaucrat-ese before having any hope of understanding it.

prepend 3y ago
I agree generally, but dcat has been really easy to implement. There’s really only 10-20 required fields and they are all pretty useful and you already know them anyway. Someone did a good job, I think, in setting this up to be functional and address the main issues that government catalogs should accomplish- what data that the people paid for are available? It’s also understandable through the json scheme if you’d like to skip the pretty easy to understand web site, https://resources.data.gov/standards/catalog/dcat-us/ https://resources.data.gov/standards/catalog/dcat-us/ My biggest fear with us-dcat3 was that it would be incompatible with 1.1. And this page says it won’t be, so I’m staying optimistic until I review.