A data-inventory workshop drops SMS complaints, transit-app clicks, and SCADA heartbeats into one unlabeled ‘sensor’ bucket. What correction should facilitators make?
Select an answer to reveal the explanation.
Short Explanation
Three very different animals got tossed in one kennel labeled ‘sensor.’ Texts are people-to-people, taps are people-to-apps, and SCADA pulses are machines-to-machines. Split the kennel or the architecture will bite later.
Full Explanation
Accurate source typology separates person–person, person–machine, and machine–machine classes. SMS complaints, transit-app clicks, and SCADA heartbeats exemplify those three classes respectively. Collapsing them into one unlabeled “sensor” bucket hides Velocity, privacy, and pipeline differences that civic facilitators must surface before tool selection.
Keeping one bucket because all civic data is identical fails by concept: types differ in authorship and risk. Deleting SMS and app clicks because only SCADA counts as Big Data fails by concept: P2P and P2M sources are in-scope when they stress Big Data characteristics. Renaming everything as “open data” and stopping inventory fails by concept: open-data branding does not replace typology.
Exam caveat: Classify SMS as P2P, app clicks as P2M, and SCADA as M2M—do not collapse into a vague sensor or open-data label.
Operational check: Re-tag the workshop inventory into the three classes, note privacy and Velocity differences per class, and only then shortlist ingest tools. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.