Year: 2004

Categories
Technology

Back to biz

My internet connection burst back into life after we replaced the cable wire, so I was able to return to work on getting my Mac ready for Open Source development.

Installing and configuring MySQL and WordPress was quite simple, and matched the instructions at MacZealots; except that I am using an older PHP/MySQL client, with it’s older password authentication, and got this error:

Client does not support authentication protocol requested
by server; consider upgrading MySQL client.

Instead of opting to update my PHP install at the moment, I just updated the passwords using the MySQL command line and SET PASSWORD:

SET PASSWORD FOR ‘username’@’localhost’ = OLD_PASSWORD(’password’);

Now I am working at installing OsCommerce and possibly Drupal, and all the software I need. This has been an amazingly uncomplicated process. Much simpler than setting up the same environment in Linux.

If you want to see the weblog, just access http://localhost/wordpress/.

(Hee hee hee. I am an evil woman.)

Categories
RDF Technology

Wiki and Weblogs

Recovered from the Wayback Machine.

Tim Bray wrote a short note on weblogs and wikis, basically saying that contrary to assertions at Sun and elsewhere that the two are convergent, they’re both very different:

A wiki is a collaborative construction engine, with refactoring and edit-in-place being the dominant forms of activity, and many equal voices singing in a chorus. A blog is more like a content faucet, a source with one voice, always growing at one end; while updates to existing content are OK, the dominant activity is pouring new text and pictures and whatever in.

I can agree that out of the box, the two are very different; not only in implementation, but also in purpose and audience. However, that’s out of the box. It doesn’t take much to morph the one into the other, which I assume is where some of the discussion of convergence enters. (Not to mention that both are considered forms of personal empowerment.)

For instance, a wiki can easily be setup to only allow one editor, and limit one’s work to adding material rather than editing. And as can seen in the Kitchen, it’s not difficult to open a weblog up to the world, and the only thing stopping people from editing their work is habit and etiquette.

This latter is where the difference arises: the technology isn’t limiting how each tool is used, as much as our assumptions on how each is supposed to be used. The most significant assumption is that each writing on a weblog is relatively static and usually is identified by the author. In a wiki, the writing is usually not static and identifying your writing with your name is discouraged to prevent ownership of the material.

Further on, when Tim says that weblogging isn’t anything new, it’s because personal webpages controlled by one individual have been around since the web’s been invented. However, a wiki, with it’s lack of voice other than the corporate whole, and based on an almost universal trust, is very new.

Think of the difference politically: weblogs are Libertarian, while wikis are Green.

(Via Danny)

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
Technology

Extending the Syndication feeds

I have never been one to jump on the syndication and aggregator wagons, following all the latest innovations. I still don’t provide full feeds for my syndication feeds at Burningbird; and I think Podcasting is half craze, half pirate radio station without the élan of continually escaping the clutches of the FCC.

But I do provide feeds and use Bloglines to keep up with the webloggers I read. Well, I did.

One of the problems I’ve found with Bloglines, and I imagine the same can be said for all syndication tools, is that they only provide part of the information I need about a weblog–they tell me when someone has updated. That’s good, and helps me keep up to date with my favorite reads. But what about the people who don’t update? It can be a long time before I notice that one person I read hasn’t updated for a time, perhaps even weeks. All of a sudden I think to myself, “Hey, I haven’t heard a thing from so an so for the longest time. Where are they?” and rush over to their site, only to discover that the writer has quietly folded up his or her tent and drifted away. I wasn’t even there to say good-bye, because the loss of communication doesn’t show up in my aggregator.

When I accessed the sites I read through a blogroll, I would go through the list once a day; I would notice if the person hadn’t updated. I would also notice new site designs, new comments, and various other tidbits of information that just don’t through a syndication feed, and aren’t picked up by an aggregator.

If you read hundreds, even thousands, of feeds a day, you need an aggregator. There is no better tool to use to keep up with that flow of informaiton. But if you’re like me, the flow of information isn’t as important to me, as reading a new essay by a favorite writer, and why hasn’t he updated in ever so long?

Aggregators and syndication feeds need to capture new information, such as the following:

  • How long it’s been since a person last updated.
  • Recent comments (yes I know these can be syndicated, but I want an overall activity report for the site).
  • A note that the person has redesigned their site, and I should stop reading their posts in the aggregator and go take a look and comment.
  • An indicator if the person seems discouraged because not enough ‘real people’ are clicking through and they wonder if they’re read.
  • A flag that something isn’t right with the person, which can only be deduced when looking at all of the their writing on one page, one post after another.
  • A suggested style, soft, faded gray, when the weblogger is gone forever.
Categories
Technology

Disconnected connected development

I do most of my development on remote servers, either at my client’s or my own sites. However, when contemplating server-side development in a disconnected environment, I had to decide if I wanted to create the local work space on my PC or my Mac.

The PC has more space, but most applications run into problems when working with Windows. I should say, most open source applications run into problems when working in Windows. In addition, I haven’t upgraded my Linux dual-boot in the longest times, and frankly, just wasn’t that interested in dealing with it at the moment.

My Mac, a PowerBook G4, 500 MHz with 512MB of memory has a Unix core underlying all that bubble stuff. I’ve used up much of the disk space, though I am clearing it and putting all my photos on CDs. The big question is will everything I need work on the Mac?

From a software perspective, what I need is a working install of MySQL, PHP, Apache, WordPress, and OsCommerce. And possibly Drupal. The Drupal and OsCommerce are for clients; the WordPress is for my work on Wordform.

Tiny bits of research later: MacZealots covers getting WordPress and MySQL running so that takes care of that. (It also has a guide on installing Drupal.) And I’ve found an installation guide of putting OsCommerce on the Mac. Not only that but there’s a support forum for Mac users running OsCommerce.

My Mac has now gone from being just my main photography/Adobe Photoshop site, to my new open source development machine and photo site. I hate to sound like a Mac bigot — but I am really turning into a Mac bigot. I love my Mac, even if I still haven’t gotten that damn battery lose yet.

I still use the Windows box, though. You know, for old times sake.