Marcin Chojnacki w projekcie zajmuje się głównie zdobywaniem danych z zewnętrznych systemów bazodanowych. Z uwagi na obszar pracy w ramach Shared Cities jest to przede wszystkim Facebook (otwarte API) oraz serwisy informujące o wydarzeniach kulturalnych w Katowicach, np. silesiaspace.pl. Mowa tu o postach, komentarzach, wpisach ze stron wskazanych przez pozostałych członków zespołu zadaniowego. W przyszłości czeka go jeszcze m.in. zmiana formatu dostępnych danych – tak by informacje z Facebooka można było połączyć z danymi opisującymi obiegi kultury także z innych serwisów, np. katowickiej Ultramaryny.

Dawid Górny jest odpowiedzialny m.in. za wybór narzędzi i środowisk, których cały zespół używa do komunikacji oraz do pracy z danymi. Kluczowym kryterium doboru oprogramowania jest możliwość wymiany i łączenia różnych typów danych. Wspólnie z Marcinem przygotowuje skrypty, dzięki którym pobierane są dane np. z mediów społecznościowych. Stale rozwija także nowe metody pozyskania danych z kolejnych źródeł. W dalszej części projektu będzie tworzył narzędzia i interfejsy do analizy i prezentacji danych online.

• Łukasz Mirocha: Jakie kroki trzeba podjąć, by przekształcić zbiór surowych danych w wiedzę zrozumiałą dla szerokiego grona odbiorców?

Marcin: Surowe dane wymagają odpowiedniego przetworzenia. Zewnętrzne serwisy nie zawsze pozwalają na bezpośredni dostęp do interesujących nas danych. Musimy je najpierw usystematyzować, następnie zapisać lokalnie na naszym serwerze, by zachować bieżący stan i mieć do niego ciągły dostęp. To jest pierwszy krok, po którym następuje właściwa praca badawcza.

Dawid: Nie można także zapomnieć o kwestiach podstawowych – jeszcze przed pobraniem danych należy odpowiednio przygotować serwer, repozytorium, bazę danych i potrzebne skrypty – kluczowe narzędzia, bez których praca badawcza z pozyskanymi danymi nie byłaby możliwa.

Marcin: Dlatego właśnie korzystamy z szerokiego wachlarza narzędzi i środowisk. W tej chwili pracujemy z MySQL Workbench i Graph Explorera API Facebooka. Dane pobieramy dzięki Facebook SDK v5 for PHP spiętego z bazą za pomocą MySQL Improved. Zdarza się, że konieczne jest opracowanie własnych narzędzi tylko po to, by wykonać pojedyncze zadanie, np. w celu odfiltrowania niepoprawnych znaków stosuję własną aplikację w C#.

Dawid: Warto wymienić także JavaScript, Node.js, Google Places API, Mapbox, Microsoft Cognitive API i OpenCV. Praca z danymi w projekcie o rozmiarach Shared Cities wymaga opracowania powiązanej ze sobą siatki oprogramowania, stąd taka różnorodność narzędzi i metod.

• Jakie wyzwania napotykacie zwykle podczas pracy z danymi? Czy często okazuje się, że zaplanowany scenariusz działań trzeba na bieżąco modyfikować w odpowiedzi na problemy?

Marcin: Problemy możemy napotkać już na etapie przygotowań, a więc podczas zapoznawania się z dokumentacją źródła danych, która bywa nieaktualna lub niekompletna. W wypadku popularnych źródeł danych, takich jak Graph API dla Facebooka, można posiłkować się jeszcze wątkami dostępnymi w sieci na forach dla programistów. Jednak niektóre funkcje deweloperzy pozostawiają rozmyślnie ukryte, ponieważ dostęp do nich daje zbyt wiele możliwości „osobom postronnym”. Gdy dokumentacja jest pełna i funkcjonuje już jakiś czas, scenariusz pracy jest dość łatwy w opracowaniu. Na etapie pozyskiwania danych z Facebooka wielokrotnie miałem do czynienia z sytuacją, w której coś albo nie działało zgodnie z dokumentacją, albo taka „dodatkowa” funkcjonalność pozwalała mi na dostęp do danych spoza dokumentacji, co poprawiało naszą skuteczność pracy.

Dawid: Mówiłbym nie tyle o scenariuszu, co o powiązanych ze sobą etapach, które składają się na nie do końca liniowy proces. Często bowiem trzeba powrócić do poprzedniego etapu, np. kiedy chcemy uzupełnić zbiór danych lub przetworzyć go ponownie pod kątem poszukiwania odpowiedzi na nowe pytania, o których wcześniej nie pomyśleliśmy. Może się także okazać, że używane narzędzie lub biblioteka wymaga wyeksportowania lub przeformatowania struktury przechowywanych danych.

• Czy często w pracy pojawia się problem niespójnych zbiorów danych?

Marcin: Tak. Jak dotąd wszystkie zbiory danych, z których pobierałem informacje, miały inny format oraz wymagały indywidualnego podejścia. Niektóre informacje trzeba rozbić na różne kolumny, np. adres miejsca wydarzenia z jednej linii dzielimy na osobne pola: ulica, miasto, kod pocztowy. Nie wszystkie bazy pozwalają na pobranie tych pól osobno. Ze zbioru należy także usunąć mało użyteczne dane, czyli takie, którymi nie byliśmy zainteresowani – np. ilustrujące wydarzenie w innym województwie, zakwalifikowane w wyniku błędu w opisie jako odbywające się w obrębie Katowic.

Dawid: Wielokrotnie okazywało się, że dla niektórych danych z Facebooka nie dysponujemy szczegółowymi informacjami topograficznymi lub adresowymi. Z pomocą przychodzi wtedy skrypt, który na podstawie Google Places API wyszukuje nazwę miejsca lub fragment opisu z adresem. Nasze zbiory danych składają się z kilkudziesięciu tysięcy rekordów, konieczna jest zatem automatyzacja procesu uzupełniania informacji, a także ich eksport do bardziej przyjaznych formatów np. Google Spreadsheet. Pozwoli to na „ręczną” weryfikację poprawności zbioru przez wolontariuszy.

• W badaniu obiegów kultury w Katowicach korzystacie zarówno z danych pobranych z Facebooka, jak i z tradycyjnych ankiet. Na jakim etapie zbiór zawierający oba te typy danych zostanie wykorzystany do opracowania ostatecznych wizualizacji?

Dawid: Muszę przyznać, że na początku projektu nie byłem świadomy tego, jaką objętością danych będziemy dysponować. Już samo przeprowadzenie badań ankietowych na taką skalę, dotyczących obiegów kultury, jest dosyć unikatowe. Połączenie obu typów danych będzie wyzwaniem nie tylko pod względem technicznym, ale i metodologicznym, co pewnie potwierdzą koleżanki i koledzy z zespołu badawczego. Trudno na tym etapie jednoznacznie powiedzieć czy informacje pozyskane w wyniku ich analizy będą wobec siebie komplementarne, czy też będą się wykluczać, na pewno jednak poszerzą pole badawcze i pozwolą na sformułowanie nowych pytań.