John Beieler

Just a comment on the usefulness. We're still using this wrapper in our deployment and it's worked great.

Definitely agree, and this is a thing that has been plaguing us for awhile. It breaks [hypnos](https://github.com/openeventdata/hypnos/issues/4) downstream and causes other [issues](https://github.com/openeventdata/petrarch2/issues/15) as well. I don't think those particular fields...

First, a question. You're using PETRARCH and not PETRARCH2, correct? Second, echoing @philip-schrodt's comments, there tends to be a pretty heavy skew towards the "verbal" CAMEO codes. You can see...

There's only a limited amount that can be done to "improve" the distribution. To a large degree it is what it is; people make statements far more often than people...

@philip-schrodt any thoughts?

This already exists at https://github.com/openeventdata/petrarch2/blob/master/petrarch2/data/config/PETR_config.ini. Additionally, the deployed version of the pipeline has always specified a separate config file for PETR with the dictionaries living in a top-level directory. You...

I thought about doing MD5 hashes for something like URL + date, but it might be more useful to have something sequential and meaningful. Easy answer is why not both?

I'm fine with hashing the text and putting in both sequential and fully unique ID. I'm also fine with the 8-digit date rather than the 6. I wonder if @philip-schrodt...

It should also probably be noted that things like: ``` {(u'---COPLEG', u'---GOV', u'041'): [[u'CALLED'], [u'HAS']], u'actorroot': {(u'---COPLEG', u'---GOV', u'041'): [u'', u'']}, u'actortext': {(u'---COPLEG', u'---GOV', u'041'): [u'deputy ... Congress', u'Governor']}, u'eventtext':...

Re-upping this since I discovered it again. The tuples as keys thing needs to be fixed ASAP since it's breaking hypnos.