Category: Technology

Categories
Technology

Bye bye Windows Bye bye Linux

Recovered from the Wayback Machine.

Over the last several months, I’ve been moving more and more of my work from my Windows/Linux dual-boot laptop to my Mac. Now with the open source development environment working so effortlessly in my PowerBook, there’s little reason to stay with my other machine.

I still get Excel spreadsheets and Word documents, but today I upgraded my OpenOffice environment to 1.1.2, and the performance and ease of use with this application has now reached a point that I can do without Office. My printer doesn’t work with my Mac, but to be honest the print drivers don’t work with many of my Windows applications. Besides my roommate’s printer just died, and he could use a new one.

Next week I’ll take my Powerbook down to the Apple Store, to the so-called Genius Bar (how pretentious can one get?) and have them fix the battery, and tell me how much it would cost to upgrade my hard driver to a larger size. After that, I’ll spend the next week cleaning out my Windows laptop and re-installing the software from scratch; giving the box and the printer to my roommate and buying a new photo-capable printer, desktop keyboard and possibly a stylus and pad for my Mac. (Suggestions on all of these would be welcome.)

At that point, for the first time since I was a tester of the earliest beta release of Windows, back in the 80’s, I won’t be using a Windows box as my primary work machine.

A few years ago, I never would have thought this could occur. I had written a best-selling book on COM/COM+ and ASP for O’Reilly, I was a member of the Microsoft Development Network, had passed several Windows certification tests, attended Windows conferences almost exclusively, and programmed primarily in VB and VC++ and just a little Java. In addition, I scoffed at the Macs with their cute graphics, and decided if I were to go with a second environment, away from my beloved Windows, it would be Linux.

This weekend, though, I was able to install several open source applications far more easily than I ever could on Linux, primarily because Mac users won’t tolerate piecemeal packages, cryptic installation instructions, and a hackers attitude of “well, if you have to ask how something works, you shouldn’t use it”. Best of all, they work out of the box on the Mac — no mucking around with Windows ‘tweaks’.

I am now become one of the Mac people I used to look askance at years ago; you know, the starry eyed ones that wax on and on enthusiastically about their machines. However, I draw the line at standing in line for an Apple Store opening, or spending time in the Mac forums comparing the size of my local Genius Bar with those of other members.

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.