noted on Mon, 09 Feb 2004
noted on Fri, 19 Dec 2003
noted on Tue, 07 Oct 2003
Plug-in: meta_date
The inspiration for this plug-in came from a Google search result that turned up an HTML archive of a w3c mailling list. The particular search item was interesting because the date of the file was displayed right beside the size of the file. I thought that if anyone wanted to check how ‘new’ a particular page was, they would merely need to see that information.
This particular plug-in will work fine for all static and dynamic blosxom blogs, but only with the characteristic that permalinks will refer to one specific post, instead of a page containing a series of posts, like the date archive.
While the plug-in works, the benefits to adding a date is still a bit nebulous in my mind. Questions that come up for me include:
- If this is present, and someone does a search with Date constraints, does Google use the meta tag in favour of the date/time it last indexed that page?
- The yyyy-mm-dd format is a part of an ISO 8601 specification, which you can see a note about from the W3C NOTE-datetime document. I have not seen many pages that use this tag, and I’ve seen even less documentation about it. Does Google only care about the year/month/day, or would they also readily parse the time of day? Not knowing the answer, I’ve provided support to provide the time of day in the meta tag. After Google re-indexes my site, then I hope to see what the results do. If they do nothing, then I may turn it off by default in the plug-in.
Mind you, when I say that the benefits of this plug-in is nebulous, it’s not to say that I don’t know what it would be good for, but rather, I’m not sure what good it will do. You may wish to read my post on Using Google to Create Comment Threads to see what use I’d put the date tag to.
Download the plug-in here. It requires Blosxom 2.0.
Blosxom Plug-in: personLink
Jon Udell wrote what I thought was a fascinating article about the trend for social software to require that you specify the kind of relationship you have with another person.
In his article, Jon wonders aloud why he can’t submit a URI or three that can do a far better job of describing the relationship than any ontology devised by those interested in creating these social webs. Quoth Jon:
The sum of my relationship with “R.” is: 1) he wrote some cool software that I tried and wrote about, and 2) we had an exchange, more recently, in the comments area of a website. And guess what? When I google for “R.’s” last name and mine, the first two hits correspond exactly to those two points. If there were a freeform input box, I’d have simply entered the query. (emphasis mine)
After a brief exchange with Jon, I started to do some musing of my own, and realized that we don’t really need webware to help us develop our social networks. There may be a need to manage those networks, however.
So, I put thoughts to deed and whipped up my first Blosxom plug-in (yay, me!) that looks for names in a post, and generates Google search queries that will demonstrate what public relationship, if any, I have with that person. You can download the plugin right here. Note: you should either save the contents of that link, or view-source, then save.
New Version 0+2i I have created a personLink icon that can be configured to be displayed immediately after the name. I’ve also added customization options for how you want to set up the link. You may now choose to link only the name and not display the icon, link and display both name and icon, or link only the icon.
You are welcome to link directly to the personLink icon at http://www.tenletters.com/rhahn/images/personLink.gif, or to download your own copy. I recommend setting the border of the image to 1 so that people can tell whether they clicked the image or not. Update: I don’t like the image; I’m going to rework it a bit. For now, I’m not using it; when I get something I like, I’ll upload it and turn it back on again.
If you like this plugin, please let me know. I have a couple of other ideas to try out on it, and would like to discuss them with anyone who has tried this plug-in.
Crufty Permalinks.
On the Blosxom users mailing list (found at Yahoo), there was a thread started by Dave Walker, who wanted to know if there was a way to make Blosxom URL’s less crufty.
Out of this thread came two links of note. The first was Dave’s inspiration to pose the question. The second is an old essay written by Tim Berners-Lee.
Then a guy who goes by the name Ben wrote this
And in it he said the coolest thing:
“In this light, the HTML is cruft if the person is only trying to access the story and does not care about the format. If, however, the person is specifically trying to access the HTML version of the story, the extension is necessary and worthwhile.”
Given that, I think that if you were to type something like this: http://www.tenletters.com/rhahn/category/entry, then what I ought to have returned is a list of possible representations for that entry to choose from.
Let me illustrate. Suppose you have a Blosxom blog with 4 formats: .txt, .html, .print, and .rss. if I punch in http://www.tenletters.com/rhahn/category/entry, then I should see something like this:
plain text: http://www.tenletters.com/rhahn/category/entry.txt
HTML: http://www.tenletters.com/rhahn/category/entry.html
Printable: http://www.tenletters.com/rhahn/category/entry.print
RSS 0.91: http://www.tenletters.com/rhahn/category/entry.rss
Seems like a good idea, but we’ll need to answer some tough questions.
What format should this representation be in? My suggestion would be to emit unflavored XHTML, and use only tags that also exist in HTML 3.2 and up. That means using these tags: <html>, <head>, <title>, <body>, <p>, <h[1-6]> and <a> — no other. My rationale for this is that by keeping it this simple, if a text browser requests it, they can still see the information, and it’s easy to parse. If a web service requests it, then they can parse the document as being well formed, even if it doesn’t ‘know’ what the semantics of the markup should imply. And, if it’s a web browser making the request, which will happen almost all the time, then it’ll still display properly.
Won’t this mean an extra click to get to the stuff you want? Yes, but here’s a possible workaround: we can use cookies to remember the ‘preferred representation’ and serve that instead of the menu from here on out, and should the menu need to be requested, then either the cookie gets expired, or a .menu would be added to the permalink.
What impact would this have on search engines? Probably none, since you’re returning an HTML document with links the spider can follow.
What about first impressions? What would the behaviour be if a visitor goes to http://www.tenletters.com/rhahn/, assuming that is the ‘home page’ of the blog? In this case, no menu would be visible, because the web server would have been configured to serve the default file type when given either a domain or directory name - typically, an html file.
Won’t that be confusing? I don’t think so. What we’re talking about is the best way to represent a permalink, and as far as I know, I don’t think people normally browse a site through permalinks.