Zegar w katerdrze Santiago de Compostela. By Luis Miguel Bugallo Sánchez (Lmbuga Commons) [CC-BY-SA-2.5-es], via Wikimedia Commons |
Nic tak dobrze nie ilustruje trudności, jakie napotyka tłumaczenie języka ludzkiego na język komputerowy, jak zapis jednostek czasu. Kalendarz którym się posługujemy pochodzi z roku 46 BC (wprowadzony przez Juliusza Cezara) z późniejszymi poprawkami z roku z 1582 (papieża Grzegorza VIII). Jest to najpopularniejszy, ale nie jedyny kalendarz, są inne w szerokim zastosowaniu jak Hijri, Hindu, kalendarz chiński czy hebrajski. W kalendarzu gregoriańskim podajemy dzień, miesiąc i rok, i wydaje nam się, że komputery powinny te ‘proste dane’ zawsze zrozumieć. Niestety, prostota ta jest bardzo pozorna.
Pierwszym problemem jest zapis daty. Po polsku zapisujemy 2 VI 1945 albo 11 września 1950 albo 3.4.23. Po angielsku zapisujemy 3/4/23 co może znaczyć 3 kwietnia 1923 roku albo 4 marca 2023 roku, zależnie od kraju i domyślnego wieku. Do niedawna komputer nie umiał zrobić nawet tak prostej konwersji, dziś próbuje odgadnąć język, którym się posługujemy, i czasem udaje się zgadnąć (a czasem nie) właściwą datę z zapisu.
Drugim problemem jest zapis czasu. W USA doba jest podzielona na godziny ‘ranne’ oznaczane AM i ‘popołudniowe’ – PM. Ale nikt nie chce się umawiać w poniedziałek o 12 AM ani we wtorek o 12 PM, gdyż te zapisy nie są jednoznaczne. Zegar 24 godzinny usuwa przynajmniej tę jednoznaczność (godzina 24:00 w poniedziałek i 0:00 we wtorek to ten sam moment w czasie, ale należący do innego dnia).
Kolejny problem to zapis z okresloną dokładnością. Ktokolwiek pracował z arkuszem rozliczeniowym, nawet tym najnowszym, wie, że można zapisać dzień (bez określenia czasu) albo czas co do minuty. Możemy więc zapisać wydarzenie które ma miejsce danego dnia, albo w danej minucie, ale nie można zapisać roku (bez określenia miesiąca), roku i miesiąca (bez określenia tygodnia), roku, miesiąca i tygodnia (bez określenia dnia), ani też tylko godziny, godziny i minuty, itp. (inaczej niż przez opisanie tego słownie, co całkowicie zbija z tropu komputer)…. i tak dalej.
Kiedy oglądamy stare zdjęcie, na odwrocie często możemy znaleźć stempelek fotografa, notatkę na temat miejsca i daty zdjęcia, a nawet kto na nim jest. Ale gdzie jest “odwrotna strona” zdjęcia cyfrowego?
EAD (Encoded Archival Description) jest standardem stworzonym specjalnie w celu zakodowania pomocy archiwalnych. Z tego powodu jest on pewnego rodzaju hybrydą. Z jednej strony stara się odzwierciedlić sposób, w jaki pracują archiwiści tworząc pomoce archiwalne, z drugiej stara się wprowadzić dyscyplinę i dokładność niezbędną do elektronicznej obróbki dokumentu. W wyniku mamy sporo dowolności w umiejscowieniu danych, co ułatwia pracę archiwiście a jednocześnie utrudnia wymianę danych. W nowej wersji EAD (EAD3), która jest w przygotowaniu od kilku lat, spodziewane jest zmniejszenie tych dowolności.
10 czerwca 2014 r. Sąd Apelacyjny Drugiego Okręgu (południowy Nowy Jork) wydał wyrok, przychylając się do argumentów HathiTrust i odrzucając apel kilku organizacji autorskich, w tym m.in. amerykańskego Authors Guild i szwedzkiego Sveriges Författarförbund. W podsumowaniu wyroku czytamy:
