A 311 resident-service analytics team prepares an open-data release and must reduce privacy risk in free-text complaint notes. What should they do during cleaning?
Select an answer to reveal the explanation.
Short Explanation
Open data should inform residents without exposing their personal details. Before publishing, redact names, phone numbers, and addresses from free-text notes; encrypting only the ticket ID leaves sensitive narrative content visible.
Full Explanation
Open-data releases of 311 complaint notes must reduce privacy risk in free text, not only in structured IDs. Stripping or redacting personally identifiable information—such as names, phone numbers, addresses, and similar identifiers—before publishing is the appropriate cleaning step for a resident-service extract. This protects residents while still allowing thematic analysis of complaint categories and neighborhoods under municipal transparency goals. Leaving names, phone numbers, and street addresses visible in the public CSV so residents can verify complaints publishes personal information and conflicts with typical open-data privacy practice. Encrypting only the numeric ticket_id secures the wrong field: the readable free-text notes may contain the sensitive content. Uploading uncleaned notes to a public chat forum for crowd editing expands exposure and creates an uncontrolled copy outside the city’s governance boundary. Exam caveat: redaction is imperfect; combine automated personally identifiable information detectors with human review for high-risk categories, and prefer suppressing entire fields when notes are too sensitive to sanitize reliably. Practical check: run detection on a pre-release sample, verify that ticket_id alone cannot recover redacted content from the public file, and retain a restricted internal copy under access control for legitimate casework.