I’ve been using my time at RepoCamp today to get the OAI-ORE plugin for WordPress validating again.  I’m having some trouble using the validator so I say that with some diffidence.  But the latest code which is now checked in to the WordPress plugins svn repo ought to be close, if not fully conformant, to the 0.9 version of the ORE spec.

I’m not sure the plugin is really useful; it’s just an Atom feed of all posts and pages in a WP instance.  I can think of some ways to make this more useful, by allowing blog authors to create their own aggregations, pulling in content outside of the particular instance.  I am certain that others can come up with even better uses.  I’m open to suggestions.

Thanks to Jay Datema for prodding me a bit, if indirectly.

This is very rough, but here’s a WordPress plugin that provides a resource map for the aggregation of all posts within an installation of WordPress. I’ll be working on this some more, but for now, it does appear to work and validate (as Atom). Useful? If so, I’ll zip it up and commit it to the wp-plugins svn.

Note:Ed reminds me that xsltproc can be used to transform the Atom-based resource map into RDF via GRDDL:

xsltproc http://www.openarchives.org/ore/atom-grddl.xsl http://lackoftalent.org/michael/blog/wp-content/plugins/oai-ore/rem.php

Update: The plugin has its own page.

Matt Zumwalt of MediaShelf, LLC has been hard at work thinking about how to make Fedora RESTful. There is now a proposal on the Fedora wiki based on a PDF he sent to the fedora-commons-developers list.

It’s an interesting proposal. I’ve read over the PDF version quickly but it does bear a closer read.

Whether SOAP or REST is more appropriate for a Fedora API is something I’m not sure about, though I don’t mean to imply it’s an either/or situation.

I was pleased to see the note that Sandy Payette sent to the fedora-users mailing list earlier today, updating the community on the Fedora 2.2 release date. Version 2.2 is going to include a bunch of features, some of which have been long-awaited and are quite, well, sexy. Some of the highlights:

• Database support has been extended to include Postgres, which should make all the MySQL-haters happy
• Fedora may now be deployed via a .war file in an existing servlet container, such as Tomcat, rather than requiring its very own Tomcat server
• A Lucene- or Zebra-backed search service has been included, which is more robust than the previous search service that used the built-in Dublin Core-populated database

These are but a few of the enhancements, and I can’t wait to put it through its paces when it’s released on January 19th.

For a more complete set of feature enhancements, click on the link above to read Sandy’s message.

Now if we can come together as a community and work on some more UIs, and get them used in some high-profile projects, many of the gripes against Fedora may be silenced. It’s still not a perfect product, but what is? That it uses XML as a storage format and exposes its functions via web-services APIs and allows use of any metadata schema, in my humble opinion, puts it head and shoulders above many other library repository solutions. And for that, it’s at least worth consideration.

I noticed Dan Chudnov’s earlier note about the launch of the unAPI website and noted in particular the the unAPI revision 1 specification.  I decided to give Technosophia a run through some error cases and some of the errors came up as 400 where they should have been 404 or 406.  I made a few minor tweaks to pbinkley’s unAPI WordPress plug-in and I believe Technosophia is now fully compliant with unAPI revision 1. 

Here are the test cases I used:

• /unapi.php
  200 Ok
• /unapi.php?uri=oai%3Alackoftalent.org%3Atechnosophia%3A25
  300 Multiple Choices
• /unapi.php?uri=oai%3Alackoftalent.org%3Atechnosophia%3A25&format=mods
  200 Ok
• /unapi.php?uri=oai%3Alackoftalent.org%3Atechnosophia%3A25&format=BADFORMAT
  406 Not Acceptable
• /unapi.php?uri=BADURI&format=mods
  404 Not Found
• /unapi.php?format=mods
  400 Bad Request

Woohoo?

Internet Explorer likes to throw the “Operation Aborted” error when trying to hook into the Google Maps API via JavaScript, at least when the JavaScript is placed where it is supposed to, i.e., a reference to the Google Maps JavaScript in the page HEAD and the actual rendering of the map within the DIV tag.

To fix this in IE, move the DIV block JavaScript code near the bottom of your HTML. Place it right between the terminating BODY tag and the terminating HTML tag. The problem seems to be that IE gets all confused when JavaScript attempts to make modifications to the page — e.g., sucking down a map from Google — while still rendering the body HTML. There are a couple other fix options here:

http://www.mapki.com/index.php?title=FAQs#Browser_Problems

It is worth noting that this “fix” does not break functionality in Firefox. And, really, who cares about the other browsers? Communists and robots, my friend.

In the HEAD of your page, you may include the initial JavaScript

<script src="http://maps.google.com/maps?file=api&v=1&key=BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH" mce_src="http://maps.google.com/maps?file=api&v=1&key=BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH" type="text/javascript"></script> 

Though it surprised me that I couldn’t remove the terminating SCRIPT tag and instead make the first SCRIPT tag self-terminating, i.e., instead of <script foo="bar"></script>, I tried <script foo="bar"/> and it didn’t work.

The JavaScript that actually renders the map within the DIV tag, cleverly named “map”, should look similar to the following:


</BODY>
<script type="text/javascript">
//<![CDATA[ 

var map = new GMap(document.getElementById("map"));
map.setMapType(G_HYBRID_TYPE);
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.centerAndZoom(new GPoint(-666.666,66.6666), 2);
map.openInfoWindowHtml(map.getCenterLatLng(), "100 Main St.<BR>Nowheresville, ZZ 99999
ZZZ");

//]]>
</script>
</HTML>