Języki z niejawną strukturą - Przegląd formatów reprezentacji modeli biologicznych

4 Przegląd formatów reprezentacji modeli biologicznych

4.2 Języki z niejawną strukturą

Języki z niejawną strukturą zgodnie z nazwą są klasą formatów, która nie jest eksponowana dla użytkownika. Celem powstania formatów tej klasy jest maksymalne ułatwienie przekazywania infor-macji wewnątrz systemów informatycznych poprzez operacje odczytu i zapisu. W efekcie pliki mogą być zapisane w postaci bardzo rozległych formatów, które swoją nadmiarowością ułatwiają prace pro-gramów komputerowych lub z wykorzystaniem symboliki, która nie jest intuicyjna dla użytkownika.

Nie oznacza to, że takich plików użytkownicy nie byliby w stanie odczytać ręcznie, ale oznacza to, że nie jest to priorytetowe.

Skupienie się, w budowaniu formatów z niejawną strukturą na ułatwieniu pracy programów komputerowych wiąże się jednoznacznie z celem stosowania takich formatów. Celem tym jest wyko-rzystanie oprogramowania, które najczęściej wykorzystuje graficzny interfejs użytkownika, który jest bardzo przystępny. Oprogramowanie, które wykorzystuje formaty tej klasy jest najliczniejsze i dla sa-mego formatu SBML istnieje ponad 250 narzędzi, które wykorzystują format SBML (Prejzendanc et al.

2016). W związku z tym, że format SBML jest przykładem standardu o dużej popularności sporo narzę-dzi stosuje rozwiązania pozwalające na zgodność z tym formatem ze względu na możliwość transfero-wania modeli do innych narzędzi. W tym celu nawet programy, które operują na formatach innej klasy tworzą funkcjonalności importu i eksportu do formatu SBML.

4.2.1 Przegląd

Pierwsza klasa, to grupa formatów pliku, która została zaprojektowana w taki sposób, aby we-wnętrzna struktura danych była ukryta przed użytkownikiem. Aplikacja zapisuje dane, utworzone przez użytkownika w konkretnym formacie, aby móc je później załadować. Każde narzędzie oparte o tą klasę formatów udostępnia interfejs użytkownika, najczęściej graficzny, a format danych jest wykorzystany jako baza danych. Takie rozwiązania są stosowane, ponieważ opieranie pracy użytkownika na interfej-sie graficznym jest wygodne dla użytkownika, nie ze względu na chronienie samej struktury danych.

Ręczne modyfikowanie przechowywanych modeli bez pośrednictwa oprogramowania, które je stwo-rzyło może okazać się trudne i niebezpieczne. Niebezpieczeństwo wiąże się z ryzykiem zakłócenia spój-ności danych, jeżeli format danych zostanie ręcznie zmodyfikowany, bez utrzymania odpowiednich ograniczeń i relacji pomiędzy elementami zapisu. Błędy popełnione przy ręcznej edycji takich formatów mogą prowadzić nawet do uniemożliwienia odczytu pliku przez oprogramowanie. Nie oznacza to za-tem, że format jest niezrozumiały, czy nieodczytywalny, ale oznacza to, że nie został zaprojektowany w celu jego ręcznej edycji. Jest to największa klasa formatów i zawiera setki przykładów. Ze względu na rozmiar listy formatów, nie będą przytoczone tutaj wszystkie pozycje. Możliwe za to jest podzielenie listy formatów na podgrupy, które zostaną poniżej wymienione.

Pierwsza i najbardziej popularna podgrupa związana jest z formatem SBML (Hucka et al. 2003), który został zaprojektowany dla ułatwienia wymiany danych w biologii systemowej, a także obszarach

pokrewnych. Zastosowanie SBML opisane zostanie na przykładzie kilku najważniejszych pozycji. Przy-kładem zastosowania SBML jest Systems Biology Workbench z modułem NOM, który został zaimple-mentowany w celu ułatwienia wymiany danych pomiędzy różnymi komponentami (Bergmann and Sauro 2006). Do rozwiązań należy również SYCAMORE (Weidemann et al. 2008), który został zaprojek-towany do wspierania tworzenia modeli. Kolejnym programem jest CellDesigner (Funahashi et al.

2003), w którym praca polega na edytowaniu modeli w postaci diagramów, które reprezentują modele związane z genetyką i sieciami biochemicznymi. Kolejnym rozwiązaniami są SBML ODE Solver (Machné et al. 2006) i Systems Biology Simulation Core Library (Keller et al. 2013).

Popularne są również inne formaty związane z inicjatywą COMBINE, które są, podobnie jak SBML, utrzymywane przez konsorcjum COMBINE. Należą do nich takie formaty jak SBGN, SED-ML, CellML, czy BioPAX (Hucka et al. 2015).

Istnieje również wiele aplikacji, które używają formatów plików zaprojektowanych specjalnie dla nich. Często jednak udostępniają również funkcjonalność importu I eksportu danych do popular-nych formatów takich jak SBML. Przykładami takich formatów, które są zaprojektowane dla swoich aplikacji są CopasiML (Hoops et al. 2006), zaprojektowany dla symulatora COPASI, BNX wykorzystany przez BiologicalNetworks (Baitaluk et al. 2006), czy CelleratorML (Shapiro et al. 2003), który jest apli-kacją MathML na potrzeby modelowania biologicznego.

Jednym z przykładów wykorzystania w praktyce języków z niejawną strukturą jest badanie Schabera (Schaber et al. 2012), który zaprezentował swoje próby odnalezienia mechanizmów moleku-larnych, które prowadziły do adaptacji przez osmozę w drożdżach. W tym celu wykorzystali 192 modele opisujące szlaki sygnałowe. Do implementacji modelu wykorzystali oprogramowanie COPASI, które po-zwoliło sprawnie przygotowywać i przeanalizować prawie 200 modeli. Ponadto oprogramowanie to umożliwiło przechowywanie modeli zarówno w formacie dedykowanym dla COPASI, jak i formacie SBML. W tym przypadku przechowywanie takiego modelu w formacie SBML pozwala na odtworzenie symulacji w innym oprogramowaniu korzystającym z popularnego formatu w celu porównania wyni-ków bez konieczności przepisywania modeli.

4.2.2 Przykład

Najbardziej popularnym formatem z niejawną strukturą jest język SBML. Jest to aplikacja ję-zyka XML, która została zaprojektowana pod kątem zapisu modeli procesów biologicznych.

<?xml version='1.0' encoding='utf-8'?>

</listOfCompartments>

<species compartment="default" id="infected

</listOfParameters>

Listing 2. Fragment modelu infekcji wirusa HCV zapisany w formacie SBML.

Listing 2 przedstawia fragment modelu infekcji wirusa HCV zapisany w formacie SBML. Przyto-czony fragment przedstawia sekcje związane z deklaracjami parametrów i agentów, biorących udział w interakcjach zdefiniowanych w modelu. Zawarty w nim jest również przykład reakcji, która opisuje proliferację zdrowych hepatocytów. Z punktu widzenia analizy interakcji w modelu najważniejsze są trzy elementy prezentowane przez Listing 2: lista agentów (ListOfSpecies), lista parametrów (ListOfPa-rameters) oraz lista reakcji (ListOfReactions).

Lista agentów przedstawia agenty, które biorą udział w modelu. Przechowywane w niej są rów-nież informacje na temat początkowego rozmiaru populacji agentów w danym modelu. Kolejnym

istot-trów, które są wykorzystywane w obliczeniach. Każdy parametr, który wpływa na wyniki obliczeń po-winien być zadeklarowany. Najważniejszym z punktu widzenia projektu modelu elementem są interak-cje pomiędzy agentami. Zapisane są w postaci listy reakcji. Reakcja opisana jest poprzez listę reagen-tów i listę produkreagen-tów. Obydwie listy składają się z agenreagen-tów, które są opisane na liście agenreagen-tów. Kolej-nym elementem opisującym reakcję jest prawo kinetyczne, które opisuje dynamikę reakcji. Może ona składać się z obliczeń uwzględniających rozmiary populacji agentów, a także wartości parametrów, które zostały wcześniej zadeklarowane. Same obliczenia zapisane są z wykorzystaniem standardu MathML, który jest uwzględniony w elemencie opisującym prawo kinetyczne.

4.2.3 Zalety i wady

Najważniejszą zaletą formatów z niejawną strukturą jest fakt, że są elementem oprogramowa-nia udostępoprogramowa-niającego interfejs użytkownika umożliwiający intuicyjne i przystępne projektowanie i za-rządzanie modelami. Jest to zasadniczy powód, dla którego omawiana klasa formatów składa się z naj-wyższej liczby dostępnych implementacji. Jednakże edytowanie modelu bez dostępu do oprogramo-wania, które wspiera format, w którym model został stworzony jest niemalże niemożliwe. Jest to pro-blem trudny do rozwiązania, szczególnie, kiedy naukowcy chcą współpracować z wykorzystaniem dro-giego komercyjnego oprogramowania lub różnych systemów operacyjnych. Wiele narzędzi może nie uruchamiać się poprawnie na Windows, Mac OS lub na Linux lub mogą wymagać specjalistycznych zewnętrznych bibliotek. Problem ten zanika w związku z rozwojem interoperacyjnych języków takich jak Java, Python, czy platforma .NET. Pomimo faktu, że większość popularnych pakietów dostarcza roz-wiązania dla różnych systemów operacyjnych, problem nadal pojawia się dla mniej popularnych narzę-dzi. Ponadto, ręczne edytowanie modelu, z wykorzystaniem edytora tekstowego, jest niewygodne i niebezpieczne dla samego modelu, ponieważ może doprowadzić do problemów z otwarciem formatu przez program, który go pierwotnie stworzył.

Kolejną ważną zaletą omawianej klasy formatów jest istnienie różnych bibliotek, które wspie-rają parsowanie SBML lub XML, co ułatwia rozwijanie nowego oprogramowania, które może korzystać z tych formatów. Niewłaściwe wykorzystanie tych bibliotek, może jednak prowadzić do dodatkowych problemów. Przykładowo, libSBML (Bornstein et al. 2008) jest obecnie wykorzystywany przez setki programów komputerowych, z których wszystkie współdzielą tą samą wersję SBML, w związku z czym powinny móc współdzielić tworzone w nich modele. Jednakże otwieranie modelu przygotowanego w jednym programie nie zawsze jest możliwe w innym programie. Jest to spowodowane trzema głów-nymi powodami. Po pierwsze jest problem pełnej kompatybilności modeli, zapisanych w tej samej wer-sji SBML. Na przykład BioPARKIN (Dierkes et al. 2011) generuje pliki SBML, które mogą być poprawnie zaimportowane przez Antimony (Smith et al. 2009). Z Antimony możemy wyeksportować plik i zaim-portować go poprawnie do programu Roadrunner (Somogyi et al. 2015). Jednakże jeżeli spróbujemy zaimportować pliki wyeksportowane przez BioPARKIN do Roadrunner, zakończy się to niepowodze-niem, pomimo, że obydwa programy wykorzystują ten sam poziom SBML i tą samą wersję SBML. Ko-lejnym przykładem jest narzędzie do edycji modeli JDesigner (Bergmann and Sauro 2006), które jest częścią pakietu SBW. Nie wspiera ono SBML na poziomie 3 i nie może czytać modeli wyeksportowanych przez Antimony. Działa ono z kolei poprawnie dla modeli wyeksportowanych przez Roadrunnera. Są to problemy, które są spowodowane słabą implementacją związaną z wykorzystaniem SBML, nie pro-blemy samej koncepcji języka, jednakże mogą powodować poważne trudności w wykorzystaniu opro-gramowania, które na nim bazuje.

Kolejnym problemem jest duża liczba wersji SBML. Dla przykładu Gepasi (Mendes 1997) wyko-rzystuje poziom 1 SBML, FASIMU (Hoppe et al. 2011) wykowyko-rzystuje poziom 2 SBML, SloppyCell (Myers et al. 2007) wykorzystuje poziom drugi w wersji 3, RoadRunner wykorzystuje poziom 2 w wersji 4, a Antimony poziom 3. Pomimo, że SBML jest kompatybilny zarówno wstecz jak i w przód, użytkownicy

powinni mieć świadomość, że w procesie importowania modelu do oprogramowania wspierającego starszą wersję języka, pewne szczególne informacje mogą zostać utracone. Ponadto mogą wystąpić problemy z importowaniem modeli do starszego oprogramowania. Na przykład Gepasi ma problem z zaimportowaniem liczb zmiennoprzecinkowych, ze względu na zastosowane kodowanie.

Trzeci problem dotyczy standaryzacji rozszerzeń SBML. Możliwe jest dodawanie nowych funk-cjonalności do SBML w postaci rozszerzeń, które są wykorzystane następnie przez oprogramowanie, które jest z nimi związane. Dla przykładu rozszerzenie FBC jest wykorzystywane przez FAME (Boele et al. 2012), czyli środowisko webowe, służące do modelowania. Pozwala ono na dodawanie ograniczeń i celów do modelu. Jednakże po zmodyfikowaniu modelu przez inne oprogramowanie, które wykorzy-stuje ten sam poziom i wersję SBML, nie obsługując jednocześnie rozszerzenia, dane związane z roz-szerzeniem mogą zostać utracone.

W dokumencie Wykorzystanie kontrolowanych języków naturalnych do modelowania systemów dynamicznych w bioinformatyce (Stron 91-95)