Skip to content
This repository was archived by the owner on Jun 18, 2024. It is now read-only.

Add accessDetails field #90

Closed
MarinaNitze opened this issue Jul 23, 2013 · 5 comments
Closed

Add accessDetails field #90

MarinaNitze opened this issue Jul 23, 2013 · 5 comments

Comments

@MarinaNitze
Copy link
Contributor

For a dataset with accessLevel = restricted -- that is, a dataset that is available only to certain people and/or under certain circumstances -- agencies need a way to describe how to access the data. Maybe you call Molly at 555-DATA, maybe you sign a contract, maybe you must be a data scientist associated with a university, etc.

An agency could potentially save time, while increasing transparency, by putting instructions in this accessDetails field instead of fielding numerous individual email inquiries.

Additionally, some datasets with accessLevel = private are still available for use by other government agencies. A data owner could choose to put an explanation for these potential use cases in this field.

Some data sets have such nuanced restrictions that the documents governing access on a per-row and per-column basis number in the hundreds of pages. Creating a whole new schema to deal with this was initially tempting, but today I think being able to drop a URL to said document into this accessDetails field would do the trick.

I am proposing this as an extensible (optional) field.

@waldoj
Copy link

waldoj commented Jul 29, 2013

Yes, now that you explain this, "private" seems woefully inadequate. I appreciate that, when agencies are generating their data inventories, and requiring an explanation for "private" will probably function as a serious block to progress, so I think making this optional (at least at first) is probably a sensible way to start. We might be wise to keep accessDetails schema-less; that is, as free-form text. Until we've got some real-world data, I'm dubious that we'll be able to envision the kind of information that will need to go in this field.

@dsmorgan77
Copy link
Contributor

This seems to be related to the suggestions outlined in #71

@gbinal
Copy link
Contributor

gbinal commented Aug 7, 2013

+1 to keeping this optional and free-form, otherwise, I'm neutral on it. If it fits DCAT norms and there's no concerns, then more consensus around optional extended fields is a good thing.

@MarinaNitze
Copy link
Contributor Author

Adjusted proposal: accessLevelComment

If accessLevel = public, you can optionally put info in here, but it's not required.

If accessLevel = restricted, you are required to put info in here about how to gain access.

If accessLevel = private, you are required to put info in here about why you are not releasing the data.

@MarinaNitze
Copy link
Contributor Author

After a bunch of discussion:

  1. The values for this field remain the same in spirit, but two are being renamed for clarity. The three choices are now "public", "restricted public", and "non-public"
  2. The accessLevelComment field is included in the proposed final 1.0 schema. See Proposed Final Metadata Schema 1.0 #44.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants