The job wiki now sorts by “last updated” by default. You can, of course, sort jobs in other ways by clicking the ’sorted by’ controls at the top of the listings.

The stumbling block had been the spottiness of SIMILE Exhibit’s documentation. Since I couldn’t figure out how Exhibit handled dates for sorting purposes, the best I’d been able to do was to get Exhibit to sort from oldest to most recently updated. That was a bit better than nothing, but not good enough. Today I found the key in the Exhibit source code. I’m posting it here for the benefit of other SIMILE Exhibit developers:

To get Exhibit to sort items by date, you need to format the dates according to the ISO 8601 date formatting standards. For instance, October 24, 2009 14:01 CDT should be formatted as 2009-10-24T14:01:00-05:00. If you’re using PHP 5+ to format your dates, you can use the string c in your date() function. (If you’re using PHP <5, use Y-m-d\TH:i:s. It doesn’t include the timezone offset, but that won’t matter for sorting purposes. Include a separate timestamp for display in your Exhibit if you’re concerned about the timezone offset.) Exhibit will correctly sort items with dates in ISO 8601 format, both ascending and descending.

There’s still one problem, though. By default, Exhibit sorts dates from earliest to latest. If you’re sorting by the timestamp of the last update for each item, you’ll probably want to default to a descending sort order. Fortunately, Exhibit lets you do that.

To control the default sort order for the items in your exhibit, set the <code>ex:directions</code> and <code>ex:possibleDirections</code> properties of your view to ‘ascending’ or ‘descending’. You can even set different defaults for different (possible) orderings. (Exhibit always defaults to ‘ascending’ if it can’t find a sort order for something.)

For instance, our job wiki has the following declaration:

<div ex:role="view"
  ex:orders=".changed_1"
  ex:directions="descending"
  ex:possibleOrders=".changed_1, .field_name_value, .field_rank_value, .field_job_status_value, .province, .tid_2, .tid_1, .tid"
  ex:possibleDirections="descending"
  ex:grouped="false"
  ex:showAll="true">
</div>

This tells Exhibit to sort the items by property “.changed_1″ in “descending” order by default. It also tells Exhibit to allow users to sort by properties .changed_1, .field_name_value, etc. Finally, the ex:possibleDirections property tells Exhibit to sort items in descending order by default whenever it’s sorting by .changed_1; because I wanted all other properties to default to sorting in ascending order, I left them all blank.

One more example: Suppose you’re working with the Nobel prize winner data from Exhibit’s Getting Started Tutorial. You want to configure your Exhibit so that when it first boots up, the Nobelists are sorted by year from most recent to least recent. You also want your users to be able to sort by name, discipline, and year. You want the default order when sorting by name to be A-Z, the default order when sorting by discipline to be Z-A (you like physics best), and year to be most recent to least recent. You would need the following code:

<div ex:role="view"
  ex:orders=".nobel-year"
  ex:directions="descending"
  ex:possibleOrders=".last-name, .discipline, .nobel-year"
  ex:possibleDirections="ascending, descending, descending">
</div>

Happy sorting!

As recaptcha.net explains, Optical Character Recognition (OCR) cannot successfully digitize all words from book images. 

reCAPTCHA takes these unreadable words and uses them to generate CAPTCHA images. When human users solve the CAPTCHA, their responses help decipher the unreadable words. (In case you’re wondering how it works, users are given two images, one successfully OCRed and another that is not. When a user gets the OCRed word right, the system assumes he/she is correct about the other word. Responses are aggregated together to improve the confidence of digitization.)

reCAPTCHA currently helps digitize books from the Internet Archive and old editions of the New York Times.

We use reCAPTCHA on two areas of the site: user registration and Phylo Forum (where visitors can post messages without registering.

One thing we haven’t fully implemented yet is a history function near the top right part of the screen. A breadcrumb will be added for each piece of content a user visits or each search a user performs. This will provide a visual way of tracing back your location as you navigate through the site.

At this point, the data is still tabular, but we’re making steady progress on our first visualization, which should be an institutional timeline. Charts, graphs, and network maps should follow in the coming months. We’ve also disabled account creation and data editing/uploading for the moment, until the rest of our initial, verified dataset has been entered.

After you’ve had a chance to play around a bit, drop us a line in the Feeback section of Phylo forum or via email (phylo@phylosophy.net) with your initial thoughts on site design and usability.

• Keywords are de-emphasized. There is no taxonomy associated with WoS (since it is so interdisciplinary in scope), so users are encouraged to search by authors (including their home institutions) and particular publications. WoS does assign keywords to articles using an algorithm that looks at titles and summaries, so users can search by topic, but it’s certainly not the preferred method.
• Influence is understood in terms of citations. Each record is tagged with as many citation links as possible (only journal articles are included). As searchers, we were shown how to find the handful of mega-articles that hundreds of other articles on a topic all cite in common. If this really is a good measure of influence, it seems possible that one could jump into any topic knowing virtually nothing about its major players and sift them out from pure citation counts.
• H-scores. Certain Doubts has had several posts about h-scores in the past few months, so I’ll simply refer you to discussions on 29 Nov, 13 Dec, 15 Dec, 17 Dec, 19 Dec, and 28 Dec.
• Search queries seem pretty user-intensive. There’s no fuzzy search capabilities (”Did you mean X?”), so there was a lot of emphasis on wild card and truncated search strings. (See below.)
• Some attempt at visualizations. I noticed two kinds of citation reports available for viewing. One shows the number of publications returned for any search; the other shows the number of citations within that publications set. These charts are static images generated upon request, and seem similar to Scopus’ visual capabilities (although I wouldn’t know because the server always times out before my image is generated by Scopus). Here are the two charts I generated for “rawls AND justice”.

WoS has data for arts and humanities going back to 1975, and I think it will be interesting to see how much it catches on in the humanities and in philosophy. One general limitation—one that I raise in the An Introduction to Phylo—is the way in which this tool makes the user do the work, rather than the other way around. I was struck by how much presenter of the session was essentially training us to work with the tool by favoring publication data over keywords and filtering searches in certain ways, rather than giving us an intuitive tool that worked however we found most natural. In general, I think this underscores the need for more participatory design in building search tools.

Beyond just asking users what they think of the tools we’ve built, we need to learn more beforehand about how they process information and in what forms they find that information most cognitively salient. I think we’ll learn some of this once we launch and revise our displays, and I hope we can come up with some model of participatory design that facilitates the process.

The choice for netMap and chronoMap was a tough one. There are few nice, open source tools out there, including prefuse, Simile Timeline, and Simile Exhibit. All of these are free, and very much in the spirit of Phylo. But each has its drawbacks, and using three different tools to run visualizations might slow down loading time and make integrating displays difficult. There’s also some worries about getting any Java-based tools to perform reliably in different browsers.

Flex overcomes a lot of these worries. It runs in a Flash environment (which is standard across all browsers) and it allows us to implement netMap and chronoMap in a single application. It also has some neat animated transitions, which you can see at http://www.adobe.com/devnet/flex/samples/dashboard/dashboard.html.

The choice to go with Google Maps API was a bit easier. The application is constantly being expanded, and there are lots of ways to customize it for our needs. Ideally, we’ll overlay some Flex elements on Google Maps, but it’s hard to say where that technology will be by the time we launch.

At any rate, you can expect to see some slick and consistent visualizations run by Flex.

• a robust tracking system that can record additions and changes, including user information and comments on why changes are being made,
• a secure sign-in area for user information,
• a search engine with advanced capabilities, and
• a general system that can be updated without heavy time investment in new coding.

drupal is one of the leading CMSes and will be able to meet all of these needs, and more. One of the most user-friendly features will be a site-wide login system. Once you’re signed in through the website, blog, or forum, you’ll automatically be signed in to the other two as well, allowing you to upload or change information, make comments, and post messages without addition logins. Hopefully this will help to encourage discussion on information, since the forum will always be one click away through the main menu.

drupal will also come in handy long-term as well. Once the core visualizations and functions are complete, we’ll be able to export a Phylo drupal module for use in other fields. So when someone in (say) English or sociology wants to create a Phylo in their own discipline, they’ll just need to install drupal and then activate the Phylo module.

The beauty of InPhO is that it’s continually updated by running statistics over SEP entries to identify likely relationships between terms. It also uses a bit of expert input to refine these relationships.

At the moment, we’re talking to Colin Allen and Cameron Buckner about using InPhO to taxonomize publication information, including dissertations. This has several upshots:

• It eliminates the need for us to create yet another keyword hierarchy in philosophy. That should keep down online clutter and free up our time to work on other parts of Phylo.
• It will standardize ontology across Phylo and SEP, which should make searching different sources easier.
• It guarantees that any keyword in Phylo has corresponding information available through SEP.

We’ll keep you updated as things develop with InPhO. In meantime, you can browse the first iteration of the ontology at http://inpho.cogs.indiana.edu:16080/taxonomy/.

One of the benefits of Worldcat.org (a free beta version of Worldcat.com) is that the site automatically detects your location based on your IP address. It then asks you to select your library from a list of libraries in your area, and saves this as a preference when you return to the site. From there, you can get one-click access to your library catalog to see whether the source is available. (You can also search other library catalogs as well.) Google Scholar also has similar functionality.

What this means is that for any person (and, in time, publication) in Phylo, you’re two clicks away from finding sources in your own library catalog.

The statistics are surprising, and not just because of the low percentage of women represented. They’re surprising because we see so little hard data about the field. It takes a huge amount of time and effort on the part of Haslangers (and Nina Emery, who she credits) to assemble this data, and even Haslanger notes throughout the article that we need more data to get a full picture of the situation. (I have heard, however, that the APA is gearing up for a demographic study soon.)

This need got me thinking about how Phylo can help fill the gap. Our database will already contain lots of information on top departments (and hopefully publications as well). By simply coding individuals as male or female, we should be able to generate statistics on

• the percentage of women in top departments
• placement figures for women PhDs
• number of appointments across a career for women
• (the percentage of women published in journals)

and all of this for any time period! The initial data won’t be totally complete because it won’t include all the top departments (or probably publications). But it will provide some good historical data, which we seem to be totally lacking. And with frequent updates and more data, Phylo should be able to provide current statistics so anyone can get a snapshot of the field at any moment.

This potential has led us to plan a new, nonvisual interface for statistical information. Call it “stats.” In principle, it would allow any user to generate statistics on any kind of data that Phylo has. (Some of our displays already do this to visualize aggregate data.) It would also allow users to export data (possibly even raw data) to analyze further in more sophisticated programs.

There’s still a lot of detail to work out here, but “stats” might fill a huge gap in quantitative information about the field. Look for it in the Lab after our big launch.

• an individuals display, which would identify personal influences on a particular
  individual, including their relationships with their teachers, graduate school peers, colleagues at appointed institutions, and dissertation advisees and committee members.
• an institutional display, which would show which philosophers worked and studied at a particular institution throughout the institution’s history, as well as the topics studied there at different times.
• an ideas display, which would reflect the intensity of study of specific philosophical ideas across time and place.

Over many conversations, we realized that these displays were running two things together: ways to visualize data (relational, chronological, geographical) and kinds of information displayed (individuals, institutions, ideas). The pairings were natural—and we still think they are—but we’ve realized that decoupling the display types from the data types opens up new options, (say) a network of citations, or a map of placement information.

Our current plan centers around three kinds of displays that can each handle any kind of information:

• netMap, a network-based display that shows relations and interconnections.
• chronoMap, a time-based display that tracks trends.
• geoMap, a geographic display that plots information in physical space.

We’ll have updates on these as we firm up which visualization tools we plan to use. We’d also like to hear suggestions about what kind of things you’d like these displays to show you about individuals, institutions, and ideas.