Add operatingUnit Field

[MarinaNitze]

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]

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

[BernHyland]

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 public-gld-comments@w3.org 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 notifications@github.com 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]

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]

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

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

[seanherron]

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

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

[MarinaNitze]

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