Frontal Lobe

My colleague Sean Thomas and I are currently working on evaluating the open-source semantic web application VIVO [ http://vivoweb.org/ ] for MIT.  Our latest investigation is how to best model grant data and relate it to other entities in the system, specifically authors and publications.

The desire is to have a better grasp on compliance with NIH (National Institutes of Health) publication requirements, specifically with PubMed and PubMed Central.

Taking some queues from how the University of Florida and Cornell have modeled this type of data, and sketching out our own pseudo-ontological mappings for entities they haven’t mapped, we’ve come up with a first draft of how we imagine this will look (below).  I’m sure this will evolve and I haven’t double-checked this for accuracy against the VIVO Core ontology, but it is at least a start…

If you work on open source projects or within distributed work environments, and meetings are scheduled and publicized in UTC, you’ll find yourself doing the time zone conversion repeatedly.

If you run OS/X, you can use the World Clock Widget to keep track easily.  The problem is that the World Clock does not come with UTC as a default option.  Fortunately, it is easy to add.

I used this article to make the modifications, and wasn’t sure if the method would work on OS/X 10.6, but it didn’t give me a single issue.  There is some iffy information in the comments of that article, so here is how I proceeded successfully:

1.)  Crack Open the WorldClock widget

Applications & widgets in OS/X are not just one file, as they initially appear, but special container objects that hold other files (essentially a special-case folder).

• Navigate to /Library/Widgets
• Right-click (or command-click) on the WorldClock.wdgt file
• Click Show Package Contents

This will open a new Finder window displaying the contents of the World Clock widget.

2.)  Edit the WorldClock.js file

If you’re not used to doing these things, this isn’t as intimidating as it might seem.  (Make a backup copy if you’re disaster-prone.)

• Find the line with the text:  “var Europe = ["
• Find the bottom of this block of text, terminated by "];“
• On the line before this, add “{city:’UTC’, offsett:0, timezone:’UTC’}“
• Be sure to add a comma to the end of the previous line, since it is no longer the last item.
• Save the file.  (You may have to authenticate in order to do this, since it is technically a system file.)

Modified "WorldClock.js"

3.)  Edit the localizedStrings.js file

There is a language localization file for all strings that appear in the widget’s interface.

• Find the directory that matches the language you are using (I modified English.lproj/localizedStrings.js)
• At the bottom of the file, add the line:  “localizedCityNames['UTC'] = ‘UTC’;“
• Save the file.

Modified localizedStrings.js

4.)  Add the World Clock widget to your Dashboard & Configure

The widget will have to be initialized with the new changes, so…

• If you have an old one, remove it.
• Add the widget to your Dashboard again.
• Click the “i” in the bottom-right corner to configure it.
• Choose Country:  Europe, City:  UTC

And there you go, a clock reading the UTC time…

mvn -N deploy

Maven help defines the “-N” option as:

-N,–non-recursive                     Do not recurse into sub-projects

Running this command in the same directory as the Parent POM (pom.xml) will result in just the parent being deployed, avoiding Maven’s attempt to traverse all sub-projects referenced.

(This all presumes that you have the correct prerequisites in place for the deploy phase, such as proper ~/.m2/settings.xml configuration and <distributionManagement> configuration present in said pom.xml.)

Thanks to Elliot Metsger of the DSpace community for this tip.

Here’s my high-level analysis of how Longwell commands are executed using HTTP calls.  The most obvious to the end user will be calls triggered by mouse-clicks in the browser, but there are a large amount of these command calls which are made within Longwell itself as somewhat of a local loop-back call that happens after the user triggers something via the UI (e.g. expanding a facet, changing the current view, etc.)

Please comment if you find any errors in the interpretation of the call structure.