-
Notifications
You must be signed in to change notification settings - Fork 601
Add accessDetails field #90
Comments
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 |
This seems to be related to the suggestions outlined in #71 |
+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. |
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. |
After a bunch of discussion:
|
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.
The text was updated successfully, but these errors were encountered: