elektronikus laborjegyzőkönyv

Segédprogramok

Sziasztok!

Az lenne a kérdésem, hogy a fenti témában van-e valakinek valamilyen tapasztalata, javaslata. Egy alapvetően molekuláris biológiai laborban használható elektronikus laborjegyzőkönyvet keresek, ami jó lenne ha tudná a következőket:

  • jegyzőkönyv oldalakra "beragasztható", mellékelhető fotók, rajzok, ábrák, táblázatok, URL-ek, stb.
  • sablon szövegek (pl. protokoll leírások) listája, beilleszthetősége (esetleg link)
  • más jegyzőkönyv oldalakra (dátumokra) való hivatkozások kezelése
  • nyílt forrású és keresztplatformos (lehetőleg Linux és Windows kliens legyen vagy web alapú)
  • jegyzőkönyvi adatok megoszthatók
  • viszonylag egyszerűen bővíthető (pl. pluginokkal, modulokkal, stb.)
  • aktívan fejlesztett

Többször is kutattam a neten és az igényekhez a legközelebb talán az ELN (http://sourceforge.net/projects/eln/) áll.

Szívesen fogadok bármilyen ötletet, hozzászólást, útmutatást, tapasztalatot! Előre is köszi!

  • 1911 megtekintés

( strapal | 2009. 12. 29., k – 18:42 )

Szerintem az A4-es spirál négyzethálós füzet a legjobb laborjegyzőkönyv. Beleírható a napi elvégzett munka, az eredmények kiértékelése; beleragasztható bármi (grafikonokon át a gélképig). Mivel a prokollokat többnyire ugyanúgy kell csinálni, elég rájuk egy sorban hivatkozni.
Én a protokollokat külön vezetem a GoogleDocs segítségével.

Ez nem holmi féléves tárgyból némi kis laborgyakorlat, hanem több év munkáját kitevő, többszáz kísérlet leírását és eredményét tartalmazó sokszáz oldalas kutatási dokumentáció. Az emlékfoszlányokról meg annyit, hogy kb. tudom, hogy mikor foglalkoztam ezzel-azzal, de még így is sokszor 15-20 perc elmegy azzal, ha keresek valamit, hogy át kell lapozzam annak az "emlékfoszlány" időszaknak a 30-40 oldalnyi anyagát.

- waiter -

GoogleDocs pl. nem jöhet szóba, mert a kutatás ideje alatt harmadik félhez nem kerülhetnek ki adatok! Amúgy sem okés, mert a már meglévő kép, táblázat, stb. file-jaimat nem elsősorban beágyazni akarom a jegyzőkönyv oldalra, hanem azt szeretném, hogy önálló file-ként meglegyenek külön (esetleg adatbázisban tárolva) csak némi meta adatokkal a megfelelő hivatkozás legyen ott a jegyzőkönyvben (ahol lehet persze, pl. képfile-oknál előnézeti kép is szerepeljen).

- waiter -

( Atis1 | 2009. 12. 29., k – 20:10 )

Hali,
Egyedi fejlesztés nem jöhet szóba?

( Aadaam v | 2009. 12. 30., sze – 00:55 )

Ez eddig a microsoft word. Az a szoftver azert tulmutat a felkover-dolt-times new romanon.

Esetleg OpenOffice.org vagy Symphony?

Weben ezt ki kene fejlesztened, vagy fogni valami open source web office-t es kiegeszitened.

( Beanie | 2009. 12. 30., sze – 04:38 )

Kicsit bizonytalan vagyok, hogy akkor most mi is a lényeg ebben? Hogy valami köztpontosított dolog legyen, amolyan jegyzőkönyvekből álló adatbázis, ami kereshető, szerkeszthető, statik lehetnek, stb. Vagy pedig egyszerűen csak a szerkesztés a lényeg? Mert ha csak szerkesztés, akkor mindenféle doksiszerkesztő dolog játszik ízlés szerint.

Ms Word / OpenOffice
HTML + MathML a képletekhez
LaTex
DocBook + MathML a képletekhez
saját XML séma stíluslapokkal

A DocBook-os megoldást részletezném kicsit, mert kevesen ismerik pedig szerintem elég jó.
- Beszúrható kép, ábra, hivatkozások, táblázatok, stb. Van amolyan callout dolog is, hogy egy mintaszövegbe (idézet, kód, stb.) kis számos ábrákat raksz be és alul magyarázod.
- Sablonszöveg megoldható XML szinten XInclude vagy XML entity segítségével.
- Sokféle hivatkozási lehetőség is van, XLink támogatás is, ezzel jó sok féleképpen lehet hivatkozni, de ehhez nem értek túlságosan, így nem tudok bővebben írni róla.
- A DocBook séma nyílt, ahogyan a transzformáláshoz adott XSL stíluslapok is. Bármilyen validátort és XSLT processzort használhatsz hozzá. (*NIX alatt libxml és libxslt az én javaslatom) Ha pdf generálás kell, akkor pedig XSL-FO processzorként Apache FOP és JEuclid is nyílt forrásúak.
- Megosztás alatt nem tudom pontosan mit értesz, XInclude vagy XML entity-ként lehetnek közös adatok redundanciacsökkentés miatt, illetve így később újra fel tudsz használni dolgokat.
- Mivel ez markup, ezért plugin, modul nem igen értelmezett. De a sémát bővítheted új elemekkel, utána meg a bővítéseket implementálod a stíluslapba, hogy a kimenetben is olyan legyen, amilyet szeretnél. Esetleg ha valami olyan adat van, amit külön XML sémában tárolnál, azt előfeldolgozásként lehet DocBook-ba XSLT-vel és utána az egészet renderelni.
- A séma az 5.0 óta kevéssé fejlesztett, mivel nem nagyon van értelme állandóan változatni mindent, de a stíluslapok aktívan fejlesztettek, illetve az XML feldolgozó eszközök is.

Minta doksik, hogy kb. hogy néz ki a kimenet:

http://kovesdan.org/files/szabtech.pdf
Ez egy szabályozástechnika házi, a konzulensnek annyira tetszett, hogy meg is kérdezte mivel csináltam. A tartalomjegyzék automatikusan generálódik, az ábrák külsőleg tárolt képek voltak, a képletek pedig MathML-ben vannak leírva.

http://kovesdan.org/files/szakdoga.pdf
Ez a szakdogám. A forrásban a fejezetek külön fájlokban vannak a jobb áttekinthetőség miatt, a feldolgozás során XInclude ragasztja őket össze. Látsz benne bibliográfiai hivatkozásokat, ezeket automatikusan számozza, a markup alapján a kimenet ISO szabványos bibliográfia. Egy helyen van lábjegyzet is, ezeket is automatikusan számozza a markup alapján. Vannak kiemelten megjelenő megjegyzések és figyelmeztetések, illetve kódrészletek is másképp rendelődnek. A függelékben a calloutra is van példa, illetve a legvégén egy szójegyzék.

Ha érdekel a DocBook, keress nyugodtan, szívesen segítek elindulni benne.

Köszi a tippeket! A DocBook-ot megnézem! Mindenképpen érdekesnek tűnik! :) Ha elakadok, lehet, hogy megkereslek. Előre is köszi! :)

Ja, pl. rögtön egy kérdés. Megoldható-e olyasmi, hogy pl. egy képre "ráhúzok" egy újabb réteget, amire nyilazok, firkálok? Fontos, hogy az eredeti képfile megmaradjon, de a digitális jegyzőkönyvben jó lenne, ha a feliratozással együtt szerepelne. Elég lenne, hogy csak karakterek kerülnek fel.

- waiter -

Az MS Word egyébként mióta nyílt forrású és mióta keresztplatformos? Az OpenOffice.org Writer igen. Eddig abban van a legtöbb dolgom, de több ok miatt sem jók a klasszikus, irodai szövegszerkesztők.

1. Vagy egy nagy file-t csinálok és akkor néhány száz oldal jegyzőkönyv után kezelhetetlen méretű monstrum lesz az egész vagy szétszabdalom kisebb darabokra és akkor meg nehézkessé válik egy rakás dolog (pl. hivatkozás generálás, keresés, stb.).
2. Az is probléma, hogy pl. tetszőleges, bináris formában tárolt nagy mennyiségű adatot (BLOB) nem elegáns és nem is hatékony dokumentum file-ba beágyazni (ilyenek pl. DNS chip adatok vagy kromatogrammok).
3. A Microsoft se véletlenül csinált ilyen célra külön szoftvert. FYI: Microsoft OneNote.

- waiter -

A OneNote egy aranyos szoftver, de hogy laborjegyzokonyvnek alkalmatlan, az tuti.

Az utad az a sok kis darabos dolog lesz, dokumentumtar, es a word jol kezel dokumentumok kozti kereszthivatkozasokat, mindossze egy megfelelo feluletet kell epiteni bele.

OO.org-nal a bibliografia modul alapbol beepitett. Raadasul nincsenek benne BLOB-ok, hiszen ez egy XML es a tarsfajlok, zipelve.

Alapvetoen ketfele problemad van:
- Kell neked egy szovegszerkeszto.

A DocBook egy szep gondolat, ugyanakkor gondold vegig, hogy a munkatarsaid is fogjak-e tudni ertekelni, hogy nem WYSIWYG ami tortenik. Ezek a szoftverek rendszerint eleg kenyelmetlenek, bar lehet, raketakent fejlodtek miota eltuntek a szemem elol (XMLMind egesz csinos es multiplatform is, forrasa persze nincs, ezt nem talalod ki hobbibol otthon). Egy szovegszerkeszto fejlesztesekor, mivel nagyobb kozonsegnek szolnak, sok quirk-dologra is rajottek. Az ilyenek a minikozonsegeik miatt kevesbe kenyelmesek, hisz kevesen hasznaljak oket, azok is tulnyomoreszt informatikai erdeklodesuek, akik tuljutnak az ilyen hulyesegeken, nem mondjuk szimplan vegyeszek, akiket nem erdekel tulzottan, csak menjen.

- Kell neked egy dokumentumtar, amely hivatkozasszintig lekezeli az elemeit

- Ergo, kell neked egy hivatkozas-kezelo (anchor tag) szovegszerkeszto, amely rogziti az abrak, fejezetek, tablazatok hivatkozasi alapjat. Itt mar rogton egy szuk uton jarsz, jo kerdes, a Lyx-en kivul letezik-e "nyilt forraskodu multiplatform" LaTeX, ill. rendes, nem "kezelem az XML fat, PDF-et generalni parancssorbol lehet" DocBook szerkeszto.

- Azt mondod, multiplatform, nyilt forraskod kell, vegyuk be (bar non-functional requirement)

- Miutan beszurni akarsz, kell neked egy multiplatform, OLE-kompatibilis szovegszerkeszto. A LyX meg az OOo meg tulajdonkeppen mindig versenyben van, a tobbiek nagyon kiesofelben eppen.

- A dokumentumtaraddal kell egy integracio, hivatkozasszintig le. Na, itt a LyX kezd kiesni nagyon, ha a Cross-reference modult sikerul valahogy megfelelo helyzetbe hoznod, akkor oke (ugyanaz a konyvtar? mi alapjan nezi a fajlokat?), vagy irathatsz sajatot, ugyanez vonatkozik a DocBook-okra is (vajon a DocBook szerkesztok kezelik egyaltalan az XRef szabvanyt?). A szovegszerkesztok meg mindig versenyben vannak

- A beszurashoz kellenek custom pluginek, merthogy biztos vannak meroprogramjaid, lehetoleg ezeket lehessen megirni valami egyszerubb nyelven esetleg legyen ra szabvany integracio, na a LyX itt kiesett (C++, ya sure?), Docbookok kozul nem tudom ki marad. HOPP, a szovegszerkesztok meg mindig versenyben!

Ez utobbi pontot lehet javitani azzal, ha open source, akkor vegulis... nem kell pluginezhetonek lennie, eleg ha valaki megtalalja a kodban azt a reszt, amit tovabb kell fejleszteni.

(En egy picit mashonnan tennem fel a kerdest, de tudom, megkoveznek erte: ha kelloen pluginezheto, muszaj nyilt-forrasunak lennie?)

Az elso pontban elegge a maganvelemenyem is ott van valoszinuleg mint bias, ugyanakkor meg... ezt ha masok is hasznaljak, akkor nem erdemes nekiallni custom szivatni.

Ha neki mersz allni magadat custom szivatni, vegulis... Egy kelloen jo richtextarea-s javascript komponenst is tovabb lehet fejleszteni ugy egy ev alatt, hogy hozza ezt a szintet, a hivatkozasok konnyen meglesznek (doksi.html#anchor), a mindenfele beszurogatasok viszont konnyen zatonyra futtathatjak az egesz projektet (esetleg lehet jatszani OEmbeddel: http://code.google.com/p/php-oembed/ , de nem feltetlenul celravezeto itt. A lib viszont jo, en irtam ;)

Szumma (mindenkitol elnezest):

A requirement analizis vegen a komoly szovegszerkesztok maradnak versenyben igazabol, hozzajuk van igazitott dokumentumtar kezeles is (MS SharePoint, Lotus Collaboration Suite, stb). En nem igazan latom, hogy valakinek muszaj infohippinek lennie egy laborban. Egy laborban egy adott problemat kell megoldani, kimerni a vegyuletet, szaporitani a bacikat, nezni a jelet a logikai analizatorral...

Szoval en tovabbra is azt mondom, ne haragudj: Word.

Ilyet még nem csináltam sosem DocBook-ban, ezért nem tudom, hogy lehet-e. Viszont ha más nincs, valamilyen vektoros formában tudod szerkeszteni a képet, amire így rá tudsz húzni egy felső réteget. A képformátumokban nem vagyok annyira otthon, de sokszor EPS-ben szoktak ilyen ábrákat tárolni. Ez egy nagyon jó DocBook referencia: http://www.docbook.org/tdg5/en/html/

( apal v | 2009. 12. 30., sze – 10:48 )

(la)tex; ha mindezekenfelul me'g azt sem nem akarod hogy ugy nezzen ki mint amit a kiskutya megragott.

adatok megosztasara/hordozhatova tetelere: awk (pl. egy meresi adatsort letarolsz sima txt formaban, es abbol 1 sor awk-val tudsz csinalni tetszoleges dizajnu/elrendezesu latex tablazatot... sima txt-t minden jolnevelt program tud exportalni/importalni).

Webes felületen adatbázisban tárolni a változó szöveget, képet, adatot, .... Ha szükséges, akkor az adatbázisból generálható scriptekkel latex dokumentum.

UI.: Imádok scripttel generálni latex dokumentumokat.

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

Imádok scripttel generálni latex dokumentumokat.
hat me'g mondjuk C-bo"l generalni, ha a problema kicsit bonyolultabb ;) jo is az.

Webes felületen adatbázisban tárolni a változó szöveget, képet, adatot, .... Ha szükséges, akkor az adatbázisból generálható scriptekkel latex dokumentum.
igy a tapasztalatom az volt egeszen a nyulfarknyi adatbuzeralastol egeszen a tobb teranyi feldolgozasig hogy mindent txt-be erdemes tarolni. oke, igy 2009 vegen nem hangzik tul ultimate-koprorate-enterspajz megoldasnak de 1/ barmivel hozza lehet nyulni, megnezni, beletenni, plottolni, piszkalni 2/ vicces lenne hallani a kollaboratortol/munkatarstol hogy "nem tudja megnyitni a /z o"altala egyebkent ultimate-koprorate-enterspajz-sokatfizettemalicenszert-csicsapicsanak gondolt/ programjaval". persze vannak a txt-nek hatranyai is (lassabb eleres az ascii <=> ieee konverzio miatt, nehezebb indexeles). ennek ellenere.

( igiboy | 2009. 12. 30., sze – 14:47 )

Én trac-et használok hasonló dolgokra. Bár szerintem bármelyik wiki szerü portálmotor megfelel egy ilyennek.

Hogy mit tud azokból amit irtál:
- oldalakra beilleszthető, mellékelhető fotók, rajzok, ábrák, táblázatok, URL-ek, stb.
- sablon szövegek beilleszthetősége (ha itt pl a forráskódszerü szövegekre gondolsz, vagy valami fixed width font megoldásra)
- más oldalakra hivatkozás
- webalapu
- azzal osztod meg és olyan szinten akivel akarod (jogok, stb...)
- vannak pluginjai, bár nem sokat használok belőle. (pdf export, komolyabb jogkezelés, stb...)

( turul16 v | 2009. 12. 30., sze – 18:08 )

mediawiki

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( waiter | 2009. 12. 30., sze – 18:21 )

Mindenkinek köszönet a hozzászólásokért, javaslatokért, ötletekért, segítségért! A végcél az lenne, hogy a mostani idő töredékét töltsem jegyzőkönyv vezetéssel, fotónyomtatgatással és ragasztgatással. Számomra fontos az is, amit csak a digitális tárolás nyújt (szemben a papírral), azaz könnyedén kereshető, szerkeszthető, reprodukálható és földrajzi helytől függetlenül könnyen megosztható legyen a teljes anyag.

- waiter -

( lorinczi v | 2009. 12. 31., cs – 09:41 )

További szempontokat ajánlok figyelmedbe:
- arra is gondolj, hogy ezt tíz/húsz év múlva újra fel kell dolgoznod (phd/ösztöndíj pályázat/akadémiai székfoglaló/stb) és akkor a most divatos formátumokat semmi és senki nem fogja ismerni. Ezért: .txt
- elérhet az a sorcsapás, hogy az egész művet GLP alatt validálnod kell. Az auditort meg kell győznöd, hogy mi a Te mérésed, mi másé(hivatkozással), a te géleden tényleg ez a kép jelent meg. Lehet, hogy van olyan auditor aki ezt egy webes felületnek elhiszi, de az ilyen igen-igen ritka... Ezért: füzet.
- ha statisztikát kell számolnod, és ezt M$ excel segítségével teszed, akkor gyógyszeripari körökben körülmosolyognak. A megoldás SPSS vagy SAS, vagy ha ingyenes akkor R (r-project.org). Ezért : .txt
A prezentáció készítésre ezek után: (la)tex.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

Gondolom nem a füzet/jegyzetek helyett szeretne valami elektronikus megoldást, hanem azokat kiegészítendő, a dokumentálást segítő, visszakereshető, hipertext-funkciókkal ellátott eszközre van pluszban szüksége.

A legfeljebb sortörésekkel strukturált szöveges állomány sokmindenre jó, ez igaz. Azonban azt sem szabad elfelejteni, hogy egy jegyzőkönyv tartalmazhat képleteket, lehetnek benne speciális karakterek, amit a sima txt önmagában nem tud.

Zárt formátumú dokumentumba én kutatási eredményeket, jegyzőkönyveket nem tárolnék, az egyszer biztos -- van egy rakat jegyzetem, doksim Applixware-ben megírva -- a nyílt formátumok közül válogatnék, ha egyedi doksikra lenne szükségem. Ha kereszthivatkozásos, színes-szagos,képletes-ábrás dologra, amit a kollégák felé is kell publikálni részben vagy egészben, különféle jogosultságokkal, akkor valami wiki-jellegű megoldáson agyalnék, lehetőleg xml-alapokon.

Wiki jellegü megoldást választanék. Én mondjuk trac-et használok fejlesztésekhez, tud egyebet is mint irni bele azt amit füzetbe tennék.
Milyen formátum??? Nem érdekel... amikor kell akkor pár perc alatt csinálok egy megfelelőt belőle, hisz a szöveg minimális formázással mehet bele, és a képek is meglesznek eredeti valójukban. Ráadásul folyamatosan látható mikor mit irtál bele, vagy töröltél ki, esetleg mit garázdálkodott a társad.