To scratch another itch on Planet SF (the previous itch was Venus), I’ve created a WordPress plugin that supplies up to nine widgets to display a single category of links.
This plugin now lives in its Bazaar repository: Link Category Widgets.
See also: Category Link Widgets
Planet SF has been running WordPress with the FeedWordPress plugin for a while now, but it just didn’t work very well — posts were duplicated, and multiauthor blogs weren’t handled well.
Instead of fixing it, I decided to go with Planet Planet instead. Well, sort of.
Sam Ruby has put a lot of work into a refactoring of the Planet Planet code, the result being Planet Venus. Among the most significant changes is the use of a cache directory containing Atom entries as individual files. This makes it easy to slurp the posts into WordPress, which has the advantage of giving easy access to historic posts, categories and users etc.
Prompted by a question on the planet development list I finally got around to putting together a plugin that would power a WordPress installation through the use of Planet Venus.
Installation and use of the WordPress Venus plugin (svn) is straight forward — dump it in the wp-content/plugins folder, activate it from the plugins option screen, and go to the Venus option screen to configure its options: Path to Planet Venus cache directory, update interval and whether to link from posts back to their source.
Update: This plugin now lives in the WordPress Plugin Repository.
To help develop and test my new Sparqlette service, I hacked a couple of XSLTs that might come in handy here and there…
CONSTRUCT. As can be expected, not all query results work, as the RSS specification mandates certain elements. Thus, the value of the channel’s rss:link property is taken from an XSLT parameter named _uri, the variable bindings to use for rss:link and rss:title in each item is determined via some crude heuristics, and only items that have a URI for the chosen rss:link binding are created.
Variable selection heuristics for rss:link / rss:title:
rsslink or rsstitle respectively, the bindings for that variable is used for all items.For rss:link I wanted to add another option between the two, that would locate a variable that only has bindings to URIs, but I couldn’t get it working with a single XPath expression, so I gave up.
Example RSS (view Sparqlette input parameters).
Note: This entry — as all entries in the Release category — will serve as a changelog (you can subscribe to its RSS feed if you want to make sure you don’t miss out on any updates).
Some time — actually more than a year — ago i wrote a smusher for Redland that works by rewriting nodes based on identity inference.
To begin with, it handled only IFP’s, owl:InverseFunctionalProperty, but the other day I needed it to be able to handle FP’s, owl:FunctionalProperty, as well.
A classic example of an IFP is foaf:homepage — only one resource can have some specific URI as its homepage, which is handy for identity reasoning across the Web. Just as useful is the somewhat recently added property foaf:primaryTopic, which is an FP — if a page is described in more than one place, each with a seemingly different primary topic, it can be inferred that the two “topics” are actually just one, handy when identifying movies, since almost all movies have a page describing it at the Internet Movie Data Base.
The smusher is written in C, isn’t heavily commented, has been used elsewhere without problems, and works by finding IFP’s and FP’s in the model it is smushing or by being passed a specific property to smush on — a nasty way of testing is to pass it rdf:type…
Building it should be somewhat straight forward, but the accompanying Makefile might help out here and there.
Note: This entry — as all entries in the Release category — will serve as a changelog (you can subscribe to its RSS feed if you want to make sure you don’t miss out on any updates).
The current version is 0.21 (released 2005-03-27).
UPDATE: This implementation has been updated, please see Named Graph Exchange.
Every now and then I’ve run into the need for transporting an RDF graph between triple stores. I use Redland/MySQL with contexts to store information about the origin of each triple, so up until now the only way has been to transfer the triples directly from one database to another. This is because triples are just that, triples, not quads, and RDF itself only provides reification as a way out, not a very attractive option for space and performance reasons.
There have been other approaches to dealing with graph naming in RDF, TriG is one, N3/cwm has another — here’s yet another way: Wrapping up the graphs not in a single document, but in a zip archive with an index mapping documents to names.
It may seem unwise to seemingly try to circumvent real provenance issues by “just” naming graphs, but this is only intended for exchange between trusted parties, it’s not a format that’s expected to be found and consumed as other RDF documents found on the Web.