SWIB este o conferință organizată de colegii germani de la și de . Este o conferință dedicată celor care au nevoie să se racordeze la eforturile interconectării datelor prin paradigma Linked Open Data și mai ales este un spațiu dedicat schimbului de practici.
Pentru cei interesați, deja au fost publicate prezentările pe pagina dedicată programului: .
Consultând prezentările conferinței am aflat de un proiect foarte interesant intitulat , de fapt un instrument software cu (GNU - General Public License) dezvoltat în colaborare de bibliotecile universităților Lund, Ghent și Bielefeld (descrierea poate fi accesată la pagina ).
Ceea ce mi-a stârnit curiozitatea și care mă pune să instalez o instanță este Catmandu. este un instrument de lucru cu datele. Există chiar și un blog prin care poate fi urmărită evoluția dezvoltării softwareului - . Paginile blogului sunt pur și simplu inspiraționale din care se poate învăța foarte bine și foarte rapid din tot ce au reușit să facă dezvoltatorii. Am citt cum au transformat date din ALEPH, SFX și un software local în documente MongoDB obținând o versiune FRBR-izată a înregistrărilor MARC urmând o reindexare cu Blacklight (implementare Solr). JSON este formatul obținut iar cei dintre care lucrează în sistemul de biblioteci românesc și se agață de MARC, vă atenționez că este o pistă greșită: .
Hai să aruncăm o privire în „fițuică” (fițuica sau cheatsheetul este o pagină rapidă pentru cei care doresc acces rapid la cele mai uzuale comezi sau rutine ale unui limbaj de programare sau software). Mai întâi să vedem ce știe să facă Catmandu la conversie:
# Use Catmandu Importers to read data into your environment
$ catmandu convert MARC to JSON < records.mrc
$ catmandu convert MARC to YAML < records.mrc
$ catmandu convert MARC to JSON --pretty 1 < records.mrc
$ catmandu convert MARC to JSON --fix 'marc_map("245","title");remove_field("record")' < records.mrc
$ catmandu convert MARC to CSV --fix 'marc_map("245","title"); remove_field("record");' < records.mrc
$ catmandu convert OAI --url http://biblio.ugent.be/oai --set allFtxt to JSON
$ catmandu convert OAI --url http://biblio.ugent.be/oai --set allFtxt to JSON --fix 'retain_field("title")'
$ catmandu convert SRU --base http://www.unicat.be/sru --query dna
$ catmandu convert ArXiv --query 'all:electron'
$ catmandu convert PubMed --term 'hochstenbach'
Și să vedem cam ce știe să facă și la Import / Export, tot din „fițuică”:
# Use Catmandu Store to store/retrieve data from a database
$ catmandu import JSON to MongoDB --database_name mydb --bag data < records.json
$ catmandu import MARC to MongoDB --database_name mydb --bag data < records.mrc
$ catmandu import MARC to ElasticSearch --index_name mydb --bag data < records.mrc
$ catmandu import MARC to ElasticSearch --index_name mydb --bag data --fix 'marc_map("245a","title")' < records.mrc
$ catmandu export MongoDB --database_name mydb --bag data to JSON
$ catmandu export MongoDB --database_name mydb --bag data to JSON --fix 'retain_field("_id")'
$ catmandu export Solr --url http://localhost:8983/solr to JSON
$ catmandu export ElasticSearch --index_name mydb to JSON
Dacă doriți să vă jucați cu acest software, există deja imagine virtualizată. Urmați pașii de pe blogul lor:
Există o prezentare absolut fantastică din care se poate învăța foarte mult: Creșterea la maxim a (re)utilizării metadatelor de bibliotecă folosind Date Interconectate.
Prezentarea imprimă ideea că nu există o cale prescrisă pentru a ajunge la un anumit rezultat. Este nevoie de un anumit echilibru dictat de necesitat în cazul alegerii onologiilor de lucru. Normalizarea datelor este foarte importantă pentru că este de fapt primul pas în realizarea accesului la propriile date prin construcția API-ului.
LD4L este un proiect colaborativ între Biblioteca Universității Cornell, Laboratorul pentru Inovații al Bibliotecii Harvard și Bibliotecile Universității Stanford. Este un proiect finanțat cu 1 milion de dolari de Fundația Andrew W. Mellon.
Proiectul s-a concentrat pe explorarea a șase cazuri de posibile exploatări a datelor:
1. Date bibliografice și administrarea (curation) acestora,
2. Date privind persoane și entități bibliografice,
3. Manevrarea datelor externe incluzând cele care sunt de autoritate,
4. Gestiunea grafurilor adânci (prin intermediul interogărilor sau a tiparelor),
5. Managementul datelor de utilizare,
6. Servicii three-site (ex. căutare inter-domeniu)
Primul punct constă în crearea unei colecții virtuale cu scopul de a permite membrilor comunității care sunt interesați și bibliotecarilor să creeze și să distribuie între ei colecții virtuale prin etichetarea și opțional adnotarea resurselor. Un subpunct (1.2) are în vedere folosirea informațiilor care ar ajuta cercetătorii în lucrul de zi cu zi.
Sunt câteva concluzii ale atelierului LD4L din martie, 2015 (https://wiki.duraspace.org/display/ld4l/LD4L+Workshop+Overview), peste care nu aș dori să trecem prea ușor:
- trebuie create aplicații care să le permită celor care le utilizează să facă ceva ce nu au mai făcut înainte,
- nu vorbi despre date interconectate, vorbește despre ceea ce se va putea face cu ele,
- aserțiunile extrase local ar trebui să folosească URI-uri locale indiferent că există URI-uri globale,
- privește DI (Datele interconectate - linked data) ca fiind capabile să pună împreună colecții dispersate din punct de vedere organizațional/fizic,
- bibliotecile trebuie să creeze o masă critică de date interconectate comune pentru a se asigura eficiența și beneficiul global.
În folosul proiectului, s-a constituit o ontologie specifică și aici este o mare porție foarte interesantă din care fiecare specialist ar putea învăța. S-a optat pentru punerea cap la cap a mai multor ontologii existente fără a mai crea una nouă. S-a optat pentru folosirea BIBFRAME-ului în combinație cu FOAF-ul și Schema.org. Ca surse de date și posibilități de exploatare a datelor au fost incluse VIVO, VIAF-ul și DBpedia.
Restul cazurilor pot fi consultate la pagina
Prezentarea poate fi răsfoită mai jos:
Elaborarea instrumentelor software poate fi urmărită și pe Github la
O altă prezentare deosebită este cea oferită de Pascal Christoph și Fabian Steeg privind experiența în lucru cu datele pentru a constitui un serviciu util de date pentru biblioteci. Prezentarea poate fi accesată de la http://hbz.github.io/slides/swib-15/#/
Ei bine așa cred că ar trebui să arate multe dintre serviciile bibliografice actuale: http://lobid.org/nwbib
De la Ruben Verborgh, Universitatea din Ghent cu a sa prezentare: „The Digital Cavemen of Linked Lascaux” iau o idee extraodinară la care m-am gândit de multe ori, dar niciodată nu am găsit formularea fericită:
„The best API is no API. Your website is already an API. Developers like to build complicated APIs. API keys are especially cool to build. Every feature and change comes with a high cost. If you ask for an API, you’ll get one. Ask for new representations
of your resources instead” (Slide 72, prezentare online .
„Cel mai bun API nu este un API. Siteul web propriu este deja un API. Dezvoltatorilor le place să construiască API-uri complicate. Mai ales cheile API sunt fain de construit. Fiecare caracteristică vine cu un preț mare. În loc, cereți noi reprezentări ale resurselor”.
Prezentarea care m-a determinat să scriu acest articol este cea oferită de Karen Coyle. Titlul m-a intrigat: „Greșelile pe care le-am făcut”.
Prezentarea poate fi accesată la http://swib.org/swib15/slides/coyle_mistakes.pdf
De fapt ceea ce urmărește în prezentare este să parcurgă etapele evolutive ale descrierii bibliografice începând cu anii 80, când putem vorbi despre o informatizare a bibliotecilor și ajungând până în zilele noastre cînt mare parte a eforturilor se îndreaptă în direcția adoptării FRBR-ului, BIBFRAME-ului (http://www.loc.gov/bibframe/docs/) și a RDA-ului împreună cu alte modele bibliografice.
Pe scurt:
În anii 80 realizarea a fost trecerea de la înregistrările MARC la bazele de date relaționale. Specialiștii au realizat plăcerea căutării după cuvinte cheie. În același timp s-a trecut la tranziția de la fișele de catalog tradiționale la înregistrări în baze de date. O tranziție care încă nu s-a finalizat.
Menționează dânsa că în 135 de ani încă nu am schimbat modelele bibliografice și aici sunt jalonate momente cheie.
Modelele bibliografice:
1875 regulile de catalogare ale lui Charles Ammi Cutter
- să poți regăsi o carte dacă cunoști fie autorul, subiectul sau subiectul
- regulile de colocare: regăsire după un anume autor, subiect, tip de literatură
1961 Principiile de la Paris
- pierderea accesului după subiect
- pierderea persoanei în această tranziție
1998 FRBRizarea Principiilor pentru Catalogarea Internațională
- abstractizare maximă; inadaptare la regulile catalogului convențional
FRBR
1990 întâlnire IFLA la Stockholm
- dorință de a reduce la câteva elemente
- decizie pentru studierea unor cerințe funcționale pentru înregistrările bibliografice
1992 documentul de studiu a fost finalizat
1994 apare primul draft pentru consultare
1998 apare varianta finală a propunerii
2009 apare varianta existentă
2013 este adoptat RDA-ul (implementare FRBR)
2015 După 25 de ani încă nu avem cerințele funcționale ale unei înregistrări bibliografice
Una dintre criticile adresate FRBR-ului ar fi că este prea aplecat către transpunerea într-un sistem de baze de date bazat pe relații între entități (sistemul clasic ER Entity-Relationship existent în prezent).
Raportul FRBR prezintă contradicții. Trei diagrame nu explică ce este FRBR-ul și cu toate acestea majoritatea specialiștilor cunosc FRBR-ul a fi tocmai aceste diagrame. FRBR-ul ca și diagrame este interpretat de mulți specialiști ca o structură ierarhică, care prezintă și aspecte de moștenire. Privind documentul FRBR este dificil în a aprecia granițele a ceea ce înseamnă „opera”.
Un proiect interesant menit să exploreze potențialul Datelor Deschise Interconectate (Linked Open Data) în biblioteci și muzee este ALIADA.
Un alt proiect foarte interesant este Pelagios. Prezentarea este aici:
Și rezultatul, care este inspirațional:
Concluzii privind tehnologiile:
Așa cum era de așteptat, suita tehhnologiilor implicate în realizarea instrumentelor software sunt noile ecosisteme precum MongoDb (baze de date) și Virtuoso (triplestore), JavaScript (Nodejs, Express, Gulp) și noile formate dictate de nevoia simplității datelor extrase din API-uri: JSON, JSON-LD, TSON (Turtleson). Interogările sunt făcute prin intermediul SPARQL.
Ceea ce observ este o diminuare a rolului pe care RDF-ul l-a avut încercându-se să se facă o cartografiere a corespondențelor ca în cazul JSON-to-RDF.
Ca motoare de indexare se vede preferința clară pentru Solr sau Blacklight iar când vine vorba de realizarea unui instrument de interogare/regăsire (search) nu este alternativă mai bună celei oferite de Elasticsearch.
Și nu aș putea să închei fără să vă ofer câteva endpointuri utile pentru valorificarea datelor:
1. The European Library:
2. LOD Laundromat:
3. Situația la nivel global:
Câte ceva de ronțăit în lungile nopți fără somn:
Un raport care merită citit: Analysis of the BIBFRAME Ontology
for Linked Data Best Practices -
Mulțumiri celor care au contribuit la scrierea documentului sumator al conferinței. Accesta poate fi accesat și descărcat de aici:
Multe dintre concluziile documentului au fost incorporate în acest articol ca o completare firească în studierea prezentărilor.
Arhiva twitter:
Aceasta este o conferință care crește de la an la an și sper să existe cât mai curând și participări românești