Protocol parts are missing speaker_id for mks

[alonisser]

This is makes it hard to do data analysis on this data Further explanation of the issue and the solution (from an email correspondence between me and @maryLoi )

ה Headers של חלקי הפרוטוקול הם מידע "רך" וקשה מאוד להשתמש בו לשאילתות מועילות ומבוססים בעצם על Parsing של מבנה הדף, יכול להיות בהם שם, שם שגוי, שם בסדר לא נכון, כינוי, תעתיקים שונים של השם, שם בתוספת תארים וכו'. אפשר להשתמש בזה לשאילתא "כמעט" מדוייקת בredash אבל לא בשביל להציג מידע אינטראקטיבי למשל באתר על מה החכים עושים\, איפה מדברים וכמה וכו' בפרט בהשוואות בין ועדות (השערה שלי שהתעתיקים יחסית עקיבים בתוך אותה ועדה כל עוד יש אותם פרוטוקוליסטים, אבל משתנים שאלו משתנים או בין ועדות) הפעולה שצריך לעשות היא לתקן את תהליך הבניה של Protocol parts כדי שיחובר הspeaker הנכון. אנסה לפרט את האלגוריתם ומבנה הקוד הרצוי כפי שאני מבין אותו, לProtocolPart יש Foreign key ל Person (באמצעות שדה speaker) ואותו צריך לאייש בתהליך הזה המודל הזה Person מחובר לMember (חבר הכנסת) מצד אחד ויש לו PersonAliases מהצד השני שכוללים מיפויים של שם חבר הכנסת שנתקלנו בהם לאותה ישות כל למשל: [ עיסאווי פריג`>, עיסאווי פריג`>, עיסאווי פריג`>, עיסאווי פריג`>, עיסאווי פריג`>, עיסאווי פריג`>] [ שולי מועלם-רפאלי>, שולי מועלם-רפאלי>, שולי מועלם-רפאלי>, שולי מועלם-רפאלי>] [ שלי יחימוביץ>, שלי יחימוביץ>, שלי יחימוביץ>, שלי יחימוביץ>] [ שרן השכל>, שרן השכל>, שרן השכל>] [ תמר זנדברג>, תמר זנדברג>] מהדוגמא למעלה נראה לי שהבעייתיות של שימוש "נאיבי" בחילוץ שמות member עם Like של sql ברורה אנחנו כבר "יודעים" מי חברי הכנסת שהשתתפו בישיבה אז זה מידע שאפשר להתחיל ממנו, לבנות את המיפוי של שמות אפשריים (כל הAliases של הPerson שמחוברים לMembers שהשתתפו בCommitteeMeeting הספציפי ל available_person_aliases_mapping ואותו להזין לאובייקט ProtocolPartHeaderParser שיקבל את הטקסט של הHeader ואת available_person_aliases_mapping והוא יחזיר person אם הצליח שיוזן לשדה Speaker הייתרון בזה הוא שאנחנו מבודדים את תהליך "החילוץ" מהclass הגדול והמלוכלך והקשה לבדיקה למשהו שאפשר לעשות לו Unit testing מכל הכיוונים וכך גם עתידית נוכל להרחיב ולהוסיף ולתקן אותו ובהמשך (או עכשיו אם אתה בעניין) להוסיף גם ניסיון חילוץ שני אם הראשון לא הצליח למצוא התאמה ישירה עם שימוש בdifflib כמו שעושים במתודת find של NameAwareManager לדוגמא אחרי שמתקנים את המתודה ביצירה create_protocol_parts (גם בcommiteeMeeting מודל וגם בplenum - אין לי מושג למה יש שתים ומה ההבדל בדיוק) , צריך גם לבנות management_command של django שמתקנת אחורה כדי שיהיו לנו את הנתונים האלו

Perhaps should be opened in knesset-data/django/python since part of the api moved there

[OriHoch]

I edited the description to fix the RTL

[OriHoch]

not sure I understood the problem, could you write some specific example of a problem which will be fixed by this?

[alonisser]

No protocol part in Oknesset has speaker_id field populated.. Code isn't handling this. not sure for how long but for quite a while :( None what so ever, at least for committees didn't check for plenum. So this (important) data can't be used in queries and analysis

[alonisser]

Example: for previous end of moshav mary wanted to release talking statistics by coalition/opposition for vaadat haksafim

[alonisser]

@OriHoch does knesset-data-django has person class or should I pass the available persons from the calling methods

[OriHoch]

@alonisser knesset-data-django has dependency on Open Knesset so you can use all Open Knesset code from knesset-data-django and vice-versa

however, we strive to drop the dependency of knesset-data-django on open knesset at some point.. so I would like to keep this to a minimum

having said that - feel free to write the code in Open Knesset if it's easier for you at the moment

[OriHoch]

I'll have a look at this problem because I remember it was working correctly

[OriHoch]

ok, looks like it's a very old bug (would be interesting to see if it ever worked)

yes, it will be a very good enhancement - to be able to have ID of persons linked to each protocol part

regarding repository - I guess the right place to do it will be knesset-data-django as all relevant logic is already there