Tag: data visualization

Reference and electronic file management

If you’re an 21st cen­tury aca­d­e­mic like me, you col­lect a lot of ref­er­ences, bib­li­og­ra­phy and elec­tronic ver­sions of arti­cles and books. My hard drive has a hier­ar­chy of fold­ers for PDFs, and so forth, but it is hard to man­age them. I’m mul­ti­ply­ing fold­ers accord­ing to sub­ject, and that just doesn’t work very well.

There are two solu­tions to this prob­lem that I have dis­cov­ered so far: Zotero and Sci­Plore.

Zotero

Zotero is a browser plu­gin to Fire­Fox. This is a great advan­tage for brows­ing: find some­thing while surf­ing the web and a cou­ple of clicks later it is book­marked. You can add bib­li­o­graphic infor­ma­tion and anno­ta­tions to the doc­u­ment entry.

To sum­ma­rize the — to me — impor­tant features:

  • bib­li­og­ra­phy and cita­tion management
  • able to anno­tate entries
  • able to search entries
  • able to han­dle web documents
  • able to attach links to PDFs
  • han­dles Bib­TeX format

There are many other fea­tures, of course. See the Zotero web­site for fur­ther details.

Sci­Plore

Sci­plore is built on top of Free­Mind, a mindmap­ping pro­gram. It adds bib­li­o­graphic and cita­tion man­age­ment to FreeMind’s graph­i­cal rep­re­sen­ta­tion of ideas. One could describe it as a “graph­i­cal Zotero.”

I have not (yet) done a com­plete fea­ture com­par­i­son, but at first glance, the only thing Zotero can do that Sci­Plore can­not is to cap­ture web doc­u­ments and even cap­ture ref­er­ences from some kinds of web doc­u­ments. Both han­dle Bib­TeX and PDF links. Sci­Plore per­mits one to arrange the infor­ma­tion in a visual way; Zotero uses lists.

Con­clu­sion

I have only just dis­cov­ered Sci­Plore (check out the intro­duc­tory video on the web­site) whereas I’ve been using Zotero for more than a year now as a URL link man­ager. I have not — until now — felt the need to use Zotero’s bib­li­og­ra­phy man­age­ment fea­tures. I am very happy with Bib­Desk on the Mac and JabRef every­where else. The com­mon ele­ment among all three is Bib­TeX. If I hadn’t dis­cov­ered Sci­Plore to play with, I was plan­ning on using Zotero more exten­sively to han­dle my every expand­ing list of PDFs. I’m a firm believer in “the right tool for the right job.” Every soft­ware pack­age has its strengths and weak­nesses. I try to use a pro­gram for its strengths and aban­don it for a bet­ter tool when it is weak. The key to mak­ing this prac­tice work is to insist that my soft­ware store and manip­u­late data in stan­dard for­mats. In the case of bib­li­og­ra­phy man­agers, that for­mat is Bib­TeX.

We’ll see how these pro­grams will adjust to my workflow.

Mapping the territory. Part 2.

Infor­ma­tion and knowl­edge have a geog­ra­phy, or per­haps bet­ter, a topog­ra­phy. That struc­ture is very fluid. You can see things one way and I another. Is there some way to cap­ture this “map”? Prior to the dig­i­tal age, indexes were one way to do map­ping of sub­jects. Out­lines were another ana­log method. Another use­ful approach in acad­e­mia is the bib­li­o­graphic essay, where a sub­ject is out­lined by dis­cussing the books and arti­cles that are writ­ten about it. The Ger­mans famously call such arti­cles Stand der Forschung, “State of the Art”, articles.

Enter the com­puter. As always, its best con­tri­bu­tion is automa­tion, tak­ing on the dreary repet­i­tive tasks we all hate. And it does it well. So we try to teach the com­puter nat­ural lan­guage. That doesn’t work out so well. But we keep try­ing. Topic maps are an effort to cap­ture human insights in a form that facil­i­tates col­lo­ca­tion of insights about the same sub­ject. Any­one who has used a bi-​​lingual dic­tio­nary has sam­pled one form of col­lo­ca­tion of infor­ma­tion about the same sub­ject. Topic maps are a step beyond bi-​​lingual dic­tio­nar­ies in that they can rep­re­sent exam­ples of sub­jects and even rela­tion­ships between subjects.

A Topic map™ is a set of sim­ple objects, made up of (1) the topic itself, (2) an asso­ci­a­tion or con­nec­tion to other top­ics and (3) one or more instances of that topic, just as in an index. It turns out that a TM can be rep­re­sented as a math­e­mat­i­cal entity known as a graph. This is impor­tant, because there are all kinds of things you can do with graphs, and so, you can do with TMs. Sci­en­tists use graphs to visu­al­ize com­plex data; soft­ware was devel­oped to present, edit and manip­u­late those data graph­ics in ways that helped them to under­stand their data. With the advent of the Inter­net, webs of infor­ma­tion and doc­u­ments began to grow until today its growth is expo­nen­tially explod­ing. How do we get a han­dle on all that, find­ing what we need when we need it, with­out get­ting irrel­e­vant stuff and get­ting all of the rel­e­vant stuff? How do we find pat­terns and rela­tion­ships between points of data?

What can I do with topic maps?

The obvi­ous first answer is, the same thing you can do with a map of any­thing: find where some­thing is rel­a­tive to other things, nav­i­gate there, get an ori­en­ta­tion to an entire region, get a “bird’s eye view,” or a detailed topog­ra­phy. It can be used for plan­ning work, see­ing what work is needed where. Sci­en­tists use a sim­i­lar class of visu­al­iza­tion called a map of sci­ence. What inter­ests me is that this class of visu­al­iza­tion is using text and cre­at­ing inter­ac­tive graphs. Soft­ware is being devel­oped to cre­ate TMs in auto­mated ways.

In my next post, I will describe my exper­i­ments with Wan­dora, a free but nev­er­the­less very sophis­ti­cated pro­gram to cre­ate, edit and dis­play TMs. A con­crete exam­ple will, I hope, make the poten­tial of TMs more vivid.

Mapping the territory. Part 1.

I was updat­ing one of the many bib­li­ogra­phies I main­tain (in Bib­TeX, of course!) the other day. One of the tasks when mak­ing a new entry in the bib­li­og­ra­phy is to choose key­words for that entry. This allows the bib­li­og­ra­phy man­age­ment soft­ware I use (Bib­Desk on the Apple, JabRef on Linux; although this may change once the Zotero stand­alone appli­ca­tion comes out of alpha.) to orga­nize the entries into mean­ing­ful group­ings. The list of key­words has grown in an ad hoc fash­ion. I never really gave much thought to it, think­ing the choice of terms used self-​​evident.

As I was choos­ing a key­word for a cer­tain entry, I found myself unable to do so. None of my lists of key­words really fit; yes, I could add more than one key­word, but that really did not work, either. It needed…more than one word. In a sud­den inspi­ra­tion, I looked up the book’s Library of Con­gress sub­ject clas­si­fi­ca­tion. Ah! Just what I needed. “Hebrew lan­guage — dis­course analy­sis — Con­gresses”. Here are three terms, asso­ci­ated together in a hier­ar­chi­cal man­ner. The moral of this tale is to aban­don key­words and use LOC sub­jects, no? Of course, if my entry had been a jour­nal arti­cle, I would have to choose the sub­ject myself; I could not rely upon a library sci­ence pro­fes­sional to do the clas­si­fi­ca­tion for me. Nev­er­the­less, a def­i­nite step for­ward. Or so it seems.

I proudly men­tioned my bril­liant idea to my friend, Patrick Durusau, who, among other hats, is the con­vener of one of the ISO Topic Maps work­ing groups. His reac­tion: “Well, yes, that works, sort of. Why not cre­ate a topic map of your dis­ci­pline and use that instead of key­words for bib­li­og­ra­phy sub­ject asso­ci­a­tion? It’s more gen­eral, can be more accu­rate and flex­i­ble than LOC sub­jects, and is use­ful for a lot more than just bibliography.”

Duh. I knew that. It would have come to me even­tu­ally. But how to bell the cat? I’m not sure yet. I’m work­ing on it. More anon.

//jabref.sourceforge.net/

User Interface Design Patterns

When one works in an area — it doesn’t mat­ter whether it’s in the human­i­ties or in build­ing con­struc­tion — one begins to rec­og­nize pat­terns in how prob­lems are solved. Typ­i­cal solu­tions accrue as a body of knowl­edge and are passed on to new practitioners.

In com­puter sci­ence this has been hap­pen­ing for a decade or more. “Design pat­terns”, soft­ware con­structs which have both data struc­tures and the algo­rithms to effi­ciently and effec­tively manip­u­late them, are becom­ing more and more well-​​known and well under­stood. For exam­ple, there is the “fac­tory” pat­tern, which makes “wid­gets”, defined by the pro­gram­mer. This is a com­mon task, so com­mon that it has been done many times. The gen­eral prin­ci­ples of how to con­struct a fac­tory are described, regard­less of the soft­ware plat­form or environment.

The idea of design pat­terns can be extended, and the folks at Endeca have done just that for user inter­faces (UI): the Endeca User Inter­face Design Pat­tern Library. There is no rea­son the rein­vent the wheel; this library deals with com­mon tasks or prob­lems in pro­gram­ming a UI, e.g., search, faceted nav­i­ga­tion, and infor­ma­tion dis­cov­ery. There are other UI design pat­tern libraries out there, e.g., Pat­ternry.

Why my inter­est in this? Because Patrick Durusau and I are exper­i­ment­ing with new ways of inter-​​acting with text, using the rab­binic Miqra’ot Gedolot (the Rab­binic Bible; kind of like a medieval Jew­ish “study Bible”) as a point of depar­ture for design con­cepts. We are play­ing around with var­i­ous ways of map­ping rab­binic ideas of text study to mod­ern UI con­cepts. Maybe we will come up with a design pat­tern library for the study of bib­li­cal and other ancient texts!