# Fields in TSDB++ Profile **URL:** \ **Category:** \[incr tsdb()\]\ **Created:** [May 15, 2018, 11:41pm UTC](https://delphinqa.ling.washington.edu/t/fields-in-tsdb-profile/143 "2018-05-15T23:41:12Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![davinman](https://delphinqa.ling.washington.edu/user_avatar/delphinqa.ling.washington.edu/davinman/32/13_2.png) [@davinman](https://delphinqa.ling.washington.edu/u/davinman)\ **Post date:** [May 15, 2018, 11:41pm UTC](https://delphinqa.ling.washington.edu/t/fields-in-tsdb-profile/143/1 "2018-05-15T23:41:13Z")
I’m creating a list of test cases for my phenomena, and hand-spun a TSDB++ item generator from my tables. I was having some issues until I realized that TSDB++ really wanted an integer value for the field “i-difficulty” so I just defaulted it to 1. I’m assuming this field means something like “How difficult is it to capture this sentence grammatically?” but I realized I don’t have a good understanding for all of the fields in the Relations file. I figured this would be a good place to ask. Below are the required item fields and my interpretation of them. My question is: What is the intended meaning of the fields I’ve left off or guessed at? id (integer) - Unique ID origin - speaker or location the data came from register - sociolinguistic register?? format - orthography choice?? difficulty - difficulty to parse?? category - ?? input - non-segmented orthography tokens - segmented orthography gloss - glossed segments translation - free translation wf - well-formedness (0 ungrammatical, 1 grammatical) length - number of words (why is this necessary?) comment - free comment field author - author of the test suite/test item date - date it was added (also unclear why this is necessary) ---
**Author:** ![ebender](https://delphinqa.ling.washington.edu/letter_avatar_proxy/v4/letter/e/34f0e0/32.png) [@ebender](https://delphinqa.ling.washington.edu/u/ebender)\ **Post date:** [May 15, 2018, 11:58pm UTC](https://delphinqa.ling.washington.edu/t/fields-in-tsdb-profile/143/2 "2018-05-15T23:58:29Z")
`input' is what you want the parser to process --- at least in most settings. I'm not sure what`tokens’ is. `length’ is there (I think) to support the analyses that [incr tsdb()] can give you which break down coverage & performance by sentence length. I think `category',`difficulty’, `register’ etc have to do with the TSNLP approach to testsuite construction (but I’m not quite sure). Not all of these fields are required. You might look to the make\_item script from 567 for clues: [http://courses.washington.edu/ling567/make\_item](http://courses.washington.edu/ling567/make_item) ---
**Author:** ![goodmami](https://delphinqa.ling.washington.edu/letter_avatar_proxy/v4/letter/g/b5e925/32.png) [@goodmami](https://delphinqa.ling.washington.edu/u/goodmami)\ **Post date:** [May 16, 2018, 5:36am UTC](https://delphinqa.ling.washington.edu/t/fields-in-tsdb-profile/143/3 "2018-05-16T05:36:35Z")
There are 3 data types in test suites: `:integer`, `:string`, and `:date`. The default (i.e., unset) value for the latter two is an empty string (e.g., in `...@@...`, there’s an empty string or date field in between the two `@`s), but for integer fields the default is `-1`. Integers are generally used for identifiers, lengths, or counts, and `0` is a meaningful value for these, so `-1` is taken as a non-value. There are some integer fields, called “coded attributes” (defined in `*tsdb-coded-attributes*` in [incr tsdb()]'s `globals.lisp`) for which the value does not correspond to an identifier or a scalar, but to categories (like an Enum in some programming languages). For these, the default of `-1` might not be acceptable. Those are, with acceptable default values: - `i-difficulty` (`1`) - `i-wf` (`1`) - `polarity` (`-1`) The meaning of the `i-wf` is given on the wiki ([http://moin.delph-in.net/ItsdbReference](http://moin.delph-in.net/ItsdbReference)), but the other two are not defined. I think your choice of `1` is an acceptable value for `i-difficulty` (my guess is they range from 1 to 6, but that is just conjecture (see [here](https://en.wikipedia.org/wiki/Dice_throw_(review)))). `i-format` may have to do with the kind of input data, e.g., if it’s XML, text, LaTeX, HTML, etc., but I’ve only ever seen `none` as the value of that field, so I’m not sure. I think Emily is right about `i-category`, `i-difficulty`, and `i-register`. `i-input` is the input string for the system, but this may be pre-segmented (e.g., as Jacy does), or not (as the ERG does). These strings will get tokenized, probably by a REPP, and the result (the YY tokens) is probably what could go in `i-tokens`, but I’m not sure. `i-length` is the number of words (not post-REPP tokens). For example, “Kim didn’t sleep.” is 3 words, but 5 tokens in the ERG’s tokenization (“Kim” “did” “n’t” “sleep” “.”). I’m not sure what you’d do if your language doesn’t use spaces to separate words and you use that form in the `i-input` field. Also note that `i-comment` is sometimes hijacked to embed additional fields in a Lisp S-Expression format (e.g., `(:probability 1.0) (:score 0.8)`). Most fields (including `i-date`) are not required. I think all you need is `i-id`, `i-input`, `i-wf`, and maybe `i-length`) You might find more information here: [http://www.delph-in.net/itsdb/publications/index.html](http://www.delph-in.net/itsdb/publications/index.html)