New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DP] modified/last_modified is confusing #83

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

Comments

Projects
None yet
3 participants
@besquared
Contributor

besquared commented Dec 10, 2013

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

This comment has been minimized.

Contributor

rufuspollock commented Dec 31, 2013

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

This comment has been minimized.

sballesteros commented Dec 31, 2013

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

This comment has been minimized.

Contributor

rufuspollock commented Dec 31, 2013

@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

This comment has been minimized.

Contributor

besquared commented Dec 31, 2013

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

@sballesteros

This comment has been minimized.

sballesteros commented Dec 31, 2013

+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

This comment has been minimized.

Contributor

rufuspollock commented Jan 1, 2014

@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

This comment has been minimized.

Contributor

rufuspollock commented Jan 18, 2014

FIXED.

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