Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[DP] modified/last_modified is confusing #83
There are several ways to signify when the last time a package or resource was modified.
There should be one way to determine when the last time something was modified and it should stylistically be the same as the rest of the spec.
Use the key 'lastModified' whenever and wherever you want to record when a resource or a package was last modified. It's unambiguous and matches the camelCase style that is being proposed elsewhere.
Agree on consistency. Agree on camel case. My question now would be: is it worth having this field? Why and when would you use it? Would you not get this information from some third party system or look at the version number or checksums/hashes.
So my proposal would be: deprecate and remove modified/last_modified.
@sballesteros I'm just not sure that this is actually needed - what's the use case for these fields? When do you use them? Who keeps them up to date (especially modified and published).
I say this as someone having been involved in building data catalogs / data hubs for a while (and having mysefl required these fields of others ;-) ...). I also helped put this kind of thing into schema.org ;-) - schema.org is largely based on dcat and I did a lot on the dcat spec (which itself was based on void, CKAN's data fields and dublinc core).
I guess if we do strongly want them we could have them as "Catalog" fields i.e. something the catalog would add rather than a user ...