Categories
RDF Technology Weblogging

Thinking out loud: Wordform and Dynamic RDF

Recovered from the Wayback Machine.

An issue about attaching metadata recorded as RDF/XML to a web object, particularly a web page, is that there is no clean way to embed the XML into an (X)HTML document; at least, embed the data and still have the page validate.

Yet creating separate files just for the RDF/XML can get messy, as I found when I generated PostCon data for my weblog post entries a while back.

However, with a dynamic page application, such as WordPress, another approach is to have the application provide the appropriate data, based on passed parameters.

For instance, with WordPress, attaching “/trackback/” at the end of the post name doesn’t serve up the post page; instead it triggers the trackback web services. Doing the same with “/feed/”, returns the RSS syndication feed, and so on.

WordPress also has a way of attaching keyword-value pairs to a specific post. I’ve used this data to provide sidebar meta information about a post, here and at Burningbird, and I plan on using this to more depth within Wordform, my customized fork of WordPress.

I’ve been asked whether I would be using this capability to generate PostCon entries. I could, but a slight modification of an RSS syndication feed could do this just as easily. What interests me more is the ability to support RDF/XML generation for a variety of models (i.e. specific vocabularies), architected using built-in utility functions within the weblogging tool. These then would map the data to a structure that could be used to drive out RDF/XML when attaching the specific model name to the post, such as “/postcon/” for PostCon, and “/poetry/” for the Poetry Finder.

Yeah, easier said then done.

What would be nice would be to integrate existing RDF tools and applications to handle as much as this extended semantic modeling and metadata management as possible. A PHP-based API, such as RAP (RDF API for PHP) could be used to handle much of this, and should integrate nicely into the PHP-based weblogging functionality–but how to simplify modeling relationships when your user is barely conversant with HTML, much less something more complex?

The best approach would be to use a plug-in architecture to provide simplified, user-friendly front-ends to collect the metadata based on a specific model. Based on this there would be an RDF Poetry Finder plug-in to collect the poetry metadata, which would then incorporate this data into triples in the database. Associated with the plug-in would be a backend process that maps to a ‘data type’ passed to the tool (that previously mentioned ‘/poetry/’) and generates the RDF/XML for that model.

Wordform is based on a cut of the code of WordPress 1.3, which I believe will be incorporating the capability of adding plug-ins to the administration pages–another piece of the puzzle provided. If not, this is a functionality that should be added – extending the admin UI. Without using DHTML.

So the workflow for Poetry Finder would be:

Create the post using basic weblogging functionality.
Annotate the post with poetry metadata, using the Poetry Finder administrative plug-in.
Use RAP to add the data to the database.

When the Poetry metadata is accessed, by an application passing “/poetry/” as an extension to the post name, the poetry plug-in intercepts the request, via Wordform/Wordpress filter, and uses RAP to pull the data from the database, and generate valid RDF/XML to return.

The same workflow should work with category data, and even at the weblog level. For instance, this could be used to generate a FOAF file if one wished. The strength of this approach, though, is for individual and category archives.

To make the data useful, it would then need to be aggregated, but we have successful examples of how this can be done with RSS and FOAF. A centralized store would need to be created of collected data, and be searchable, but that’s for another late night brainstorming session.

Categories
Weblogging

Pledges now, is it?

Recovered from the Wayback Machine.

Jeff Jarvis has started a pledge he wants bloggers to sign on to. It reads:

After the election results are in, I promise to:
: Support the President, even if I didn’t vote for him.
: Criticize the President, even if I did vote for him.
: Uphold standards of civilized discourse in blogs and in media while pushing both to be better.
: Unite as a nation, putting country over party, even as we work together to make America better.

I can agree without reservation to civilized discourse, though I’m not sure we understand what that is. To some, it means not calling each other names; to others, it means not to disagree. The beauty of this environment is that we each bring a different understanding. That’s also the beast.

But if Jarvis means refraining from calling each other names, then, yeah, that would be nice.

I can also agree about pulling together as a country. I think that’s going to be easier said than done, but I’m for giving it a try,

As for support, when asked to clarify, Jarvis responded with:

I mean acknowledging that the president is the president and especially in a time of war, we need to stand together against our enemies — namely, Islamofascist terrorists — and not act, as too many have during this administration (and the one before it) that the enemy is in the White House. No, we’re on the same side.

That’s a little like the logic of saying to a person, “Have you stopped beating your wife yet?” Jarvis has framed the question so that it reflects what he considers our most dangerous enemy: Islamofascist terrorists. I can’t agree with his call for support, because I can’t agree with the definition of the enemy.

You see, I consider our worst enemy to be intolerance. Intolerance on the part of some Muslims about other non-Muslim people from the west, true. But also the intolerance demonstrated in this country — towards gays, towards women, towards people of color, towards those who don’t follow what others deem the One True and Right Way.

When Jarvis says will I pledge to support the President as he combats the enemy, my answer has to be, yes, if we can agree on what is the enemy.

As for the last part, about being critical about our leaders, we shouldn’t have to take a pledge to do this — it’s part of our duty to this country to be critical. And aware.

We don’t know yet who is going to win the Presidency, the race is too close to call. Regardless of who does, I am concerned about my country and the direction it will take in the next four years. More, I am concerned about how others outside of this country will view us, we their American friends, once the results are known.

Based on this, I would like to add a fifth part to this pledge, if we can do such a thing: that we don’t hold each other’s flags as a barrier between us. It would be a shame to toss aside all the great connectivity the internet brings, just when we were starting to get it right.

Categories
Weblogging

Podcast, whether you want it or not

As per more in-depth looking at enclosures in WordPress, 1.3:

I created a new WordPress 1.3 site, and linked an old audio recording of mine (when I tried audio blogging before I decide it was not for me — and if you listen, you’ll hear why) and as you can see in the RSS 2.0 feed the MP3 file linked in the the post has been put into an enclosure. This is not an option in the weblog — you link to a video, MP3 file, or image, it will be put into the RSS 2.0 feed as an enclosure automatically.

This means aggregators can scrape these media files independent of your post.

I would strongly suggest that the WordPress developing team consider running this one past their users.

update

Since this tends to support some of the assertions that Marius Coomans made recently, I thought he might get a kick out of this post in the test weblog, where I linked directly to a photo of Jonathon Delacour’s.

As you can see in the RSS feed — this became an enclosure in my RSS feed, too.

Categories
Technology Weblogging

From WordPress to Wordform

I feel a strong urge to work on code, I’m not sure why. Perhaps it’s because code is something I can wrap my hands around…and throttle the heck out of it.

Note if you’re not a tech, much of the following is still going to be of interest if you use or plan to use WordPress. Including some gotchas.

Since I’m basing Wordform as a fork of 1.3, I’ve been looking carefully through the 1.3 code changes in the CVS repository. That’s the beauty of open source projects that post their files in a publicly accessible directory – you can reverse engineer the code, while it’s still being developed. And since I’m used to deducing functionality from code in process (which is how I wrote most of those 14 or so computer books I was involved in), I can see the directions the tool is taking. I’m finding some interesting stuff out for those of you using WordPress or moving to WordPress 1.3.

For instance, it looks like by default ,Wordpress does not provide a link in the sidebar for RSS 1.0 or Atom; it only provides links to RSS 2.0. I can’t help thinking a better option would be to provide all the links to the popular syndication feeds, and then let the people delete as needed. It’s easier for non-techs to remove an option, than it is to add an option.

It does have Atom, as well as RSS 2.0 and .92 as options in the header for autodiscovery. I would think that it’s time to drop .92 and put RSS 1.0 in, instead. But that’s just me.

Of course, you’ve probably heard about the new WordPress split of the original index.php page into multiple pages consisting of wp-footer.php, wp-sidebar.php, and so on. There’s an interesting caveat to this, in that the application looks for a user-defined page, such as sidebar.php. Only if this isn’t found, is the wp-sidebar.php page used, instead.

This is a good design decision. By doing this, when you update your WP files, you’re not overwriting your customized work. But my goodness there is a lot of files, now. I would think a better approach would be to put the default WordPress sidebar, footer, etc into a separate sub-directory–to beging to clean out the home directory. This is going to be even more critical if people choose to have different category and archive and individual pages.

There’s also a new template/theme system. I know that people can use functions to hide and show pieces of data based on a single page request versus multiple, and so on – but this isn’t intuitive for the non-tech. It would seem that the WP developers agree with me, because the new template system now defaults in favor of category, archive, date, and author individual pages and so on in the template directory if they exist–rather than feed all requests through index.php

In other words, if you’re using a custom template, such as I am at Kitchen, which is based on Gemini, and you create separate pages for individual, category, and so on entries, the system now defaults to these without you having to screw around in .htaccess.

So, for Burningbird now, I have a category.php, archives.php, individual.php, insert.php, and fulltext.php custom pages. I could create a template theme directory, call it ‘burningbird’ and drop these files into it (after first updating to 1.3 code), and I would no longer have to worry about adjusting the .htaccess entries for these items, like I do now.

Better, if I decide to impulsively switch to another theme and style, I could do so just by dropping that themes/template files on to my server, push a button on the admin page, and off I go with a completely different look and set of pages, with no code changes.

Yes, yes, you’re nodding your heads at this. You like this. Trust me, you do.

There is a slight, teeny performance hit by doing redirection in code rather than in the .htaccess. But I believe it would be negligible. Agree? Disagree?

The blog header file, which you’re not supposed to touch, has been cleaned up enormously. Now I just have to find all the bits of the code that are no longer in the file, because I have modified it.

Ouch, though! The developers are splitting DIV open and close tags across files – opening in one file, closing in another. This is going to bite people in the butt when the start to customize the pages to their look and feel.

The main index page is, of course, cleaned up considerably since much of the content for it has been split off. A basic page would have:

-Include the blog header file (for all the data query and redirection, should not change)
-Include the header file (for CSS and autolinks and that sort of thing – HEAD stuff)
-The actual post loop is kept in index.php
-Include comments template file
-A call to a function to do the NEXT and PREVIOUS post links
-Include the footer file, which includes the sidebar

The NEXT and PREVIOUS link thing is when you have more than 20 posts (or whatever count you set, in admin I believe), from a category list or archive or search, you get the next and previous links that allow you to ‘page’ through the results. Yes, this is very tasty, you’ll want this.

The comments code isn’t much changed, though I read at the 1.3 wiki about using a weighted means throttle to keep from being crapflooded with hundreds of comment spam. Hmm, will have to see. I like mine, and it works nicely. As for the rest of the code, I’ll be replacing much in the comments because I support per-post moderation, and the WordPress developers just won’t buy into this. This was one major architectural difference between the WP team and myself.

Moving on, looks like they’ve worked on and hopefully fixed the trackback and pingback problems.

In the admin files, they’ve done a lot of splitting here, too. From the wiki, it looks like 1.3 may be opening up for administrative customizations. Curious how this will work. They have removed the geo stuff from the administrative pages, and it’s being moved to a plug-in. Now this is a goodness. Most people don’t use the geo stuff, and cluttering up the admin pages with stuff that could be a plug-in is an improvement.

Still nothing on that mysterious Dashboard page. Will this end up being a placeholder for future expansion? Something dropped in at the last moment, to have people going ‘ooo’ and ‘aaaah’?

Over into the wp-includes, the engine of the tool, I found the following CVS check in comment attached to a file: Don’t forget to strip. So, don’t forget to strip when you use WordPress.

There’s a lot of clean-up in the code, and I’m really pleased to see functions that are going to be deprecated commented with the fact. What deprecated means is that the function isn’t going to be used in future versions, and is just included now so that people have at least one release in order to adjust to the function being dropped. With this, hopefully your 1.2 customizations won’t break in 1.3 (though they will in 1.4 if you don’t clean your own code up).

There’s a new class called ‘retrospam_mgr’, which I assume is focused on ‘death to all spam’ efforts.

All in all, there’s a goodly amount of cleanup and separation of data access from processing, and processing from presentation – a good three-tier split in the code. This will make it really easy to modify the code.

I am going to yank that damn convert_smilies function. Smilies are evil.

Going over to the hackers archive, I can see that there’s discussion about allowing person to replace the comment checking functionality with their own, which is a good idea – for technologists. But then, I could create a function to do my automatic moderation on posts over a week old, and you could just plop the code into your installation, and get the same functionality without having to touch code. So the idea is a win/win. I wonder if they’ll go this route.

There’s a new ’static’ page option in 1.3, which allows you to create pages such as an about page and so on that fall outside of the normal chronological flow. I used my insert post status for this, and to me, this makes more sense. In other words, don’t duplicate the same form, provide more statuses.

Anyway, this shows in the version of 1.3 we’re using at Kitchen, but doesn’t work in the version of code we have (which is a couple of weeks old).

A great deal of discussion about multiple blog support and how this is necessary for it to be considered a true CMS. I am curious – why do people think that a CMS is a multiple blog setup? There are things one can do by author and by category that could support much of the CMS functionality. So, why do people want multiple blogs, and how would they use them? I know how I used them, but I don’t think this is the same as how other people use them.

Ut ohthere’s the enclosure thing. For non-technical people, podcasting.

The two options listed, if I’m reading the mailing list entries correctly, are to provide a field, just like with trackback, that adds the enclosure to the RSS feed. Or to skim the HTML and pull out links to media automatically. (See options in thread). It looks like the decision was to automatically wrap all URLs within the post as enclosures in RSS.

Hmmm. Can’t be reading that right. I’ll have to grab the nightly and test this one, and write about it individually. This one makes no sense.

I would still need my modifications, including my anti-spam mods, my individual comment moderation, my post statuses, full text, comment editing, like comment preview, and full page preview for the editor.

For new stuff – well, I want to take a shot at adding in some more meta capability, including the Poetry Finder. I’ve always felt that the only want something like this could work, is if it gets added on to other tools. This will give me a chance to find out. The key is, being able to add sophisticated meta data such as what would be needed for Poetry Finder, but allow a person to specify their own vocabulary and map it to the data. Or choose not to have it at all.

However, you all don’t care about what I plan to do, only when I’ve done it. In the meantime, I hope this little code review of WP 1.3 has been of interest.

This thread at the support forum points to a hint at Matt’s about Magpie code for the Dashboard of 1.3.

So we all go Kubrick for design, and Magpie for aggregation in the Dashboard, and RSS 2.0 with enclosures.

Lot’s of developer decisions being made – any user feedback to any of this?

Categories
Technology Weblogging

It’s called Wordform

When developers talk about creating a software fork, what we mean is that we’re going to take a cut of the code of the original and then develop from that point on in a separate and usually no longer compatible branch.

Firefox is an example of a fork of the original Mozilla project that was so successful, it became the official browser of the project (which is why you still also have a Mozilla browser [or did, haven’t checked recently].)

Why do forks occur? Sometimes it’s personality clashes; other times it’s because the developers of the forked version have a difference vision of where the product can go. Many times the developers who create the fork are part of the original team, but not always, particularly with open source.

Can forks hurt a project? Not usually. WordPress itself is based on a fork from the weblogging tool, b2. Another weblogging tool, b2evolution, is a second fork from the original product, being developed and maintained in parallel.

If anything, a fork can help the original development team because those who are pushing for a certain direction can go off and do their thing, leaving the developers alone.

As I wrote previously, the reason I decided to finally fork is when I realized that merging my customizations into WordPress was going to become harder and harder over time, and I’m not willing to give them up. Still, I hope to keep the plug-in and theme architecture compatible so the two environments can share objects of each.

My forked version of WordPress is going to be called, Wordform. From linguistics, a “wordform” is the smallest unit of speech or writing that can stand on its own, and has a distinctive meaning. Now, if that doesn’t sound like weblogging, I don’t know what does. The name also has the added benefit of paying homage to it’s parent, WordPress.

I’m not going to set up a weblogging tool empire, and look for gold or glory. The code will be available for download, will be GPL, and I’ll be enhancing and fixing bugs. But the effort is going to be very casual.

I’m doing this project for fun, but it’s also an answer to all those people who have said to me in the past, “Well, if you don’t like (fill in the blank) why don’t you create your own weblogging tool.” So I am.