25 September 2003 Archives

Recovered from the Wayback Machine.

Thank you for sending your query to ____________ magazine. Your photographs are beautiful! The magazine has not published photo essays in the past, but that may change in the future.

I was thrilled when the managing editor of a magazine, known for the beautiful photography it uses to annotate its stories, wrote the words, Your photographs are beautiful! to me in an email response to a proposal I sent. And though this didn’t lead immediately to a gig, the editor is passing the proposal on to the editor in chief for consideration. It’s from tiny acorns such as these that little oak trees of hope blossom.

First, though, I have to build up my photo library.

I’ve finished putting my photo albums together and I have some regrets that most of the photos, taken with a digital camera, can’t be used in publications because of their low resolution. Some, but not much.

The problem with film photography is that the costs can be prohibitive, especially if you use professional film and development. With the digital camera, there were no costs involved and I felt free to experiment, try new things, explore new territory. By doing this, I was able to find not only the type of photography I enjoy – journalistic photography, not what is known as ‘art’ photography – but also to post examples online and get excellent, brilliant, and spot on feedback from readers, as I wrote about a few days ago.

In the meantime, I’m using my low resolution photos when I send out ideas to publications. However, I am not just sending queries about possible photography assignments; I’m also sending ideas and suggestions for stories, essays, and articles to technical, fictional, travel, nature, and community-based publications. This is in addition to two book ideas I’m putting together – one on technology and one that’s social/political/cultural flavored. I’m fairly sure the technical one will get a nibble, and I have hopes for the other.

If you can’t tell from this flurry of activity, I’ve stopped trying to find a fulltime computing gig. If I can find small jobs, short term contracts or gigs working at home (or abroad, which would be even better), I’ll grab them – but my days as a full time technology architect working for a single company are over. I reached burn out in California, and it shows in the interviews. My resume is too good not to have a job; it’s not the resume or my knowledge or my experience – it’s been me.

Before you all howl “Don’t quit your day job!”, be aware that I’m am looking for employment, but right now, I’m focused on temporary and seasonal work, and whatever I can grab short term. Since I no longer have to worry about bill payments other than my car and health insurance, I can get by on earning smaller amounts of money – I don’t have to go just for the high priced architect jobs.

(Anyone want a damn good technical architect or senior level software developer for a short term assignment, at basement prices? Throw in a few rolls of film, and I’m yours.)

Dorothea wrote today that she doesn’t have a lot of patience with the do-your-dream crowd. I can see her point, you have to be practical. No one is going to take care of you, you have to take care of yourself. But when you’re pushing 50 (49 in a few weeks), sometimes your dreams are the only thing that keeps you going.

I know about doing what needs to be done – when you’ve ironed ties for a living, you can hack most anything. It’s been a while since I fried hamburgers or stocked shelves, but if I must, I will. Hopefully a new book and some articles will preclude having to pursue this option, knock on squishy white bread buns. However, regardless of what I do to pay for Zoe’s kitty kibbles, I am a writer. Nothing’s going to change this but going to sleep some day and not waking up again.

My only regret is that I’m too old to get good tips as a bar maid. Darn it.

Recovered from the Wayback Machine.

The RDF vocabulary used throughout the examples for Practical RDF is PostCon, example here, a Post Content information dataset. The plan was that I would finish the book and then finish a Java implementation of PostCon, the application, using PostCon, the vocabulary, before the book hit the street.

What I wasn’t counting on was that I wouldn’t have a Tomcat server to run the Java application on when it was finished. I am running my own server, but it’s shared by other folks and at this point in time, a Tomcat server would be too much for it.

I also wasn’t counting on how tired I was once the book was finished. When you’ve worked on a book for two years, through four major rewrites trying to keep up with changing specifications and attitudes and tools, you get tired. I got tired.

However, PostCon the application begs to be created, and PostCon the vocabulary begs to be used.

So, what is PostCon? PostCon is a vocabulary that records information about a web resource, its movement, whether it’s been replaced, and why, and so on. It’s also an application that will maintain a history of your web content in a form that can be used to redirect HTTP requests when a resource is moved; track history of changes without the necessity of a complex change control system; and provide intelligent error handling when a resource is removed permanently. You can see the early prototype in action with this link.

The application has a user interface that allows one to query the PostCon record for a resource, add to it or modify it, and then persist the changes. Additionally, the application has a web services interface that can be utilized from other applications, such as weblog tools like the one I’m using for this page. Since the information about the change is persisted in a file (RDF/XML) rather than a database, other tools could access this information, such as webbots trying to new resources, or checking to see if a resource is still viable.

The vocabulary is based on RDF, and serialized using RDF/XML, so other vocabularies can be plugged in, simply and easily. Information about the creator is maintained in the PostCon vocabulary and this can be tied to the creator’s FOAF file. If the web resource is a weblog page, trackback information can be used to add PostCon related items for the specific page. For that matter, comments can also be added as part of the history of the resource – after all, a commented weblog posting is different than the posting by itself.

The long and short of it is that I’m returning to working on PostCon, but rather than work on it in the background, I’m going to implement the pieces and document them here in this weblog. This will not only give me incentive to get off my butt and get this done, but it should also, I hope, give me some decent feedback if I’m pursuing a less than efficient implementation strategy.

To start, I’m going to review the PostCon vocabulary one more time, to see how I want to modify it considering new efforts with Pie/Echo/Atom (to be called Atom it seems – thanks to Morbus Iff cutting through the crap – yay Morbus). Next, I’ll implement simple pages that can be used to read in and modify the RDF/XML files for a specific resource. I’ll be implementing these in PHP so that they can be accessed from my server. Later I may translate these to Java and JSP.

Next, I’m creating a second RDF vocabulary, this one to be used by an event queue system. When a resource is moved or removed, not only will the front end update the associated RDF/XML file for the document, it will also update an event queue RDF/XML file, which will then track the actions to be performed on the server side. I prefer this rather than having the front end pages implement file destruction or movement because it’s easier to secure a completely server-side application, then one that’s half front-end, half server.

In addition, by separating this layer of activity out, the application that will take the event queue information and do the actual work can be replaced depending on server-side languages supported, OS, that sort of thing.

I’ll create two versions of the application that processes the event queue – one in Java, one in Perl. The Java application won’t need a Tomcat server (no front end), and I don’t want to focus on just one langauge for this component of the entire system.

The final phase of implementing PostCon will be creating web services that can perform all of the functionality of the front-end interface functionality created in PHP. I’d like to implement these in Python and Perl. Perl because I want to try integrating this into a test copy of Movable Type; and Python because I want to improve my Python skills.

The code will be kept simple, and clean, with no frills. In addition, it’s pure open source, and can be copied, modified, and hopefully improved. When I’m finished, I’ll load all of the code to Source Forge.

I have other things to do, so I’m not going to be whipping this out over the next week, but it should be finished within the next month – knock on wood.