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

Add operatingUnit Field #89

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

Add operatingUnit Field #89

MarinaNitze opened this issue Jul 23, 2013 · 8 comments

Comments

@MarinaNitze
Copy link
Contributor

While datasets are ultimately owned by an agency, they are really collected and maintained on an operating unit basis. While contact names and emails may change, a dataset's associated operating unit probably will not. Making this a new, required field makes it clearer where to go with questions for the public consuming the data, the agency officials responsible for updating the metadata, and other agencies looking to access the data. It can also help agencies assess internal compliance with publishing data, and is likely to be part of an agency internal data management system for workflow purposes.

Different agencies call their sub-units different things: departments, POCs, bureaus, etc. In asking around, "operating unit" was most generic, but I'm open to an even more generic term.

What do you all think?

@waldoj
Copy link

waldoj commented Jul 29, 2013

This is the sort of proposal that is wildly obvious in retrospect. 👍 👍

@BernHyland
Copy link

Hi Marina,
A lot is known about the problem you describe & some really smart people have already cracked this nut. Agencies collect, curate and publish data in all sorts of ways with all sorts of contact information, often office emails & telephone numbers. Contact info comes in a wide variety of formats containing no name, first name, last name, salutation, title, agency, organization, and addresses -- the bane of many data administrators existence. There are policy & technology issues at play here.

IMO, the Open Data Project could do a great service to get behind, through providing input, a standard vocabulary for describing government published datasets. One such effort that has benefited from some really smart people dedicated to Web standards & government transparency is the RDF vocabulary called DCAT.[1] I'm sure there are others too, but I'm familiar with this project.

DCAT is nearly publication as an open Web standard and has been produced in a transparent, peer-reviewed manner. I encourage you to post your questions & feedback to [email protected] so we can work cooperatively to advance open government publication efforts. If you're facing some things that haven't been contemplated by DCAT, now would be a great time to address this.

Cheers,

Bernadette Hyland
CEO, 3 Round Stones, Inc
co-chair W3C Government Linked Data WG

[1] http://www.w3.org/TR/vocab-dcat/

On Jul 22, 2013, at 8:51 PM, MarinaMartin [email protected] wrote:

While datasets are ultimately owned by an agency, they are really collected and maintained on an operating unit basis. While contact names and emails may change, a dataset's associated operating unit probably will not. Making this a new, required field makes it clearer where to go with questions for the public consuming the data, the agency officials responsible for updating the metadata, and other agencies looking to access the data. It can also help agencies assess internal compliance with publishing data, and is likely to be part of an agency internal data management system for workflow purposes.

Different agencies call their sub-units different things: departments, POCs, bureaus, etc. In asking around, "operating unit" was most generic, but I'm open to an even more generic term.

What do you all think?


Reply to this email directly or view it on GitHub.

@seanherron
Copy link
Contributor

We've been playing around with this in #69 as well. Rather than add another field, what about making the organization a structured part of the unique identifier (something like hhs:fda:cder:dtp:datasetid)?

@gbinal
Copy link
Contributor

gbinal commented Aug 7, 2013

@seanherron - I see the appeal but think that keeping UI-usage utterly simple is a good thing, especially for agencies with beginner or intermediate capabilities.

@MarinaMartin - I'm open to it as an optional field but echo my comments from #93 with my concern about adding required fields unless there is a significant compelling need.

@waldoj
Copy link

waldoj commented Aug 7, 2013

I hadn't noticed the required bit. Yes, I agree that this should be an optional field.

@seanherron
Copy link
Contributor

@gbinal We need to figure out the UUID issue regardless, which is why I think this ought be linked. Perhaps this can be framed as an optional plaintext description of the org described in the ID?

@MarinaNitze
Copy link
Contributor Author

Love Sean's idea to make the organization/operating unit structured as one.

@MarinaNitze
Copy link
Contributor Author

Addressed with bureauCode and programOffice in #44. Thanks all!

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

5 participants