[DP] modified/last_modified is confusing #83

Closed
besquared opened this Issue Dec 10, 2013 · 7 comments

Projects

None yet

3 participants

@besquared
Contributor

There are several ways to signify when the last time a package or resource was modified.

  1. Resources use the 'modified' key
  2. Packages use the 'last_modified' key

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.

Proposal

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.

@rufuspollock
Contributor

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.

wdyt?

@sballesteros

I think we should align with schema.org/Dataset when possible (i.e no direct conflicts with CommonJS).
see:

and this blog post for motivations

@rufuspollock
Contributor

@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 ...

@besquared
Contributor

We should probably drop these fields for now. I'm not sure they make a lot of sense in any case.

@sballesteros

+1
@rgrp was just saying that if we were to have those, alignment with shema.org when possible could be good. Awesome that you helped with that :)

@rufuspollock
Contributor

@sballesteros agreed and good point.

Looks like we have agreement to drop for the present. Note, of course, that data package spec does not prevent anyone adding additional fields if they want to - cf #87

@rufuspollock
Contributor

FIXED.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment