A Data Model to Help End User Programmers Manipulate and Validate Data

1. A Data Model to HelpEnd User ProgrammersManipulate and Validate Data Christopher Scaffidi Carnegie Mellon University ISRI SSSG Oct 2006

2. Consider automating repetitive actions in a web browser. • Our recent contextual inquiry revealed that administrative assistants fill out many expense reports. • Given a location and date, they used a government site to find the per diem rate. Motivation

3. Web macros cannot automate this task. Existing macro tools cannot convert from two-letter state abbreviation to full state name. Motivation

4. Web macros cannot automate this task. Nor can they convert dates from MM/DD/YYYY to Month DD. Motivation

5. The world is full of “user-level” data. • Examples: • Dates • Credit card numbers • Person names • Quantities of RAM • Product codes • Such data are • “bigger” than floats and strings. • “smaller” than a database row. • typically domain-specific. • full of exceptional cases. • State names • US phone numbers • Bus route numbers • Dewey decimal numbers • Etc… Motivation

6. Tools do not “understand” user-level data such as states and dates. • Limited support for data manipulation • Reformatting data in web macros or spreadsheets • Transporting (transforming) data between applications • Limited support for data validation • Are any values mistyped? • Does the dataset contain duplicates? • Information Week respondents complained more about data manipulation & interoperability problems than about software reliability problems! Problem

7. To be useful, representations of these data must meet 3 requirements. Extensibility Different people use different data.  Let users represent the data that they care about. Shareability Different people sometimes use the same kinds of data.  Help end users find & evaluate representations of data. Flexibility Data appear in many formats, with exceptions to every rule.  Support multiple formats, and permit exceptions. Problem

8. Existing approaches do not meet the requirements. • Regexps / grammars / data detectors represent syntax, not semantics (e.g.: how to represent “FL” = “Florida”?) • Research on units typically only apply to numeric data in certain applications (e.g.: spreadsheets). • Knowledge systems (e.g.: ConceptNet) do not contain representations of data formats. • OO and formal types are too difficult for many end users and typically disallow exceptions to type rules. • Federated database systems deal with heterogeneous joins but require the attention of a professional DBA. And each lacks built-in support for helping users decide whose code to trust. Existing approaches

9. A “tope” defines the basic semantics of a single user-level data abstraction. A “tope” is a pair of functions defined by a user: • isa: string [0,1] returns a context-independent estimate of the likelihood that the string is an instance of this tope • eq: string x string  [0, 1] returns an estimate of the likelihood that the strings are equivalent, conditional on being instances of this tope Topes will be defined in files and compiled, just like types. Proposed model

10. Reformatting functions would transform instances from one tope to another. Two topes are “isotopes” if instances of one can be reformatted into the other. • fmt: string string treats the input as an instance of one tope and returns an equivalent string that is in another format Proposed model

11. Repositories would permit sharing of topes. • Topes could be implemented in arbitrary languages. • The binaries would be stored in “repositories”. • Each user might subscribe to multiple repositories: • personal repository of custom topes • university repository of organization-specific topes • general repository of generic topes • Users would be able to define new topes, search for topes, add them to their repository, and prune their repository of outdated topes. Proposed meta-model

12. A meta-model would representaspects of tope trustworthiness. • How do end users decide which topes to use? • Topes would be annotated with platform (e.g.: JDK1.5), author names, and other meta information to facilitate finding and choosing topes. • What if a tope consistently over-estimates “isa” scores? • Let the user give feedback, either positive or negative. • “Wrap” the tope and correct for its bias (renormalization). • What other renormalization might be handy? • Words in the context might “cue” that certain tope instances are nearby; “isa” functions for those topes may be more trustworthy in that context. Proposed meta-model

13. Macro tools would download topes on demand from repositories. Back to the macro example… • The macro tool retrieves topes. • The tool tries to infer a tope for each value in the macro. • The user could override this assignment, of course. • The tool can now automatically reformat data if needed Tope implementation

14. Most isa functions could be implemented with an augmented context-free grammar. • We logged data from information workers’ web browsers. • It appears that most data can be recognized using probabilistic context-free grammars with constraints on the grammar terms. • E.g.: time  HH : MM ap HH, MM  ## {MM >= 0 && MM <= 59 && … } • I will need to… • Verify that an augmented grammar is expressive enough • Identify what constraint primitives are necessary Tope implementation

15. Most equivalence and reformatting functions are built from very few primitives. • Equivalence functions combine • Lookup in hard-coded tables • Arithmetic and conditionals • Numeric comparisons • “Identicalness” comparison • Case-insensitive comparison • Reformatting functions combine • Lookup in hard-coded tables • Arithmetic and conditionals • Permutation Tope implementation

16. A prototype system will help userscreate, compile, and share topes. • I will need to provide a prototype system with… • A user-friendly editor for end users to define topes. • A program that turns these definitions into binary modules. • A repository server to store binaries and the meta-model. • Remember: Sophisticated end users (or professionals) can fall back on an arbitrary language to create topes. • The simple grammar language is for the common case. Tope implementation

17. Equipping tools with topes will help users create programs of higher quality. • During end user programming, tools would download useful topes from repositories. • Web macros could perform reformatting automatically. • Improved composability of web macros • Spreadsheets could be checked for malformed values. • Improved correctness of spreadsheets • Web applications could validate & reformat data from web. • Improved security of applications Applications of topes

18. Providing a tope system to users will improve data interoperability. • When receiving data, users could define a new tope (or use an existing tope) and apply it to validate data. • Users could reformat values to a uniform format. • Users could find and remove duplicate values. • Data could carry along tope definitions, particularly if the representation is “secure” (e.g.: context-free grammar) • a form of self-describing data. Applications of topes

19. Thank You… • To Mary Shaw, Brad Myers, Robin Abraham, Allen Blackwell, Margaret Burnett, Michael Coblenz, Allen Cypher, Sebastian Elbaum, Martin Erwig, Josh Gross, John Hosking, Andy Ko, Andhy Koesnandar, Henry Lieberman, Ericka Orrick, John Pane, Mary Beth Rosson, Jeff Stylos, Steve Tanimoto, and others for helpful discussions. • To NSF for funding