Categories
RDF

This is RDF: The BB Reading List

Recovered from the Wayback Machine.

Below my Virtual Neighborhood is my Bb Reading List. This list is generated automatically using PHP from an RSS file (books.rdf), which is being build using the exact same technology as that used for ThreadNeedle.

Though I didn’t use RSS as a dialect of RDF for ThreadNeedle due to the hierarchichal relationship of a threaded dialog, RSS is an ideal match for a book list such as this because the list is a “grouping of like items”– the business model for RSS.

As this time I’m using the Dublin Core and Taxonomy RSS modules, with the addition of my own items. I’m planning on generalizing my added elements into a “books” module to add to the RSS specification, once I make sure something like this doesn’t already exist.

Note that the RSS is going to be changing. For instance, I’m adding separate elements for author because there might be more than one author, and I want to be able to access each discretely. Additionally, I’ll be using the taxonomy elements instead of Dublin Core’s subject, because a book’s subject can be more complicated then that shown for just the subject element. I’ll also most likely add multiple recommenders, as more than one person can recommend a book.

By automating the book list from an RSS file, I can pull out an ISBN number and use this to look up prices at Glenn Fleishman’s Book Comparison web site. Eventually, this could also interact with something such as the St. Louis Library Catalog Search, if the functionality is accessible as web services.

Think of it: we’re only a few small steps away from the following scenario:

 

Grabbing an RSS book reading list from your favorite weblogger, feeding this into a specialized application, clicking a link on each book to open a page containing:

All the Google listings for that book
–All the Google listings for each author of the book
—- Possibly even a Google listing of related subject matter
A catalog search for that book in the libraries in your area
A price comparison and availability of the book from several online book stores
Which bookstores in your area have the book in stock and their prices
A listing of all reviews of the book

…all based on a level of trust built into the RSS file through the associated person(s) or organization(s) making the recommendation, and the weblogger the list is pulled from,

…all from the same functionality, almost literally, as is being used to build ThreadNeedle.

 

(Note, list is still being updated – special thanks to Jonathon and Karl for listing so many great recommendations, which I’m still adding to my database. And you both let me know if you want an RSS file of your own once I work out the RSS module and vocabulary. I’m sure we can work out a cookie exchange.)

Categories
Political RDF Writing

Debate at the eye of the needle

As noted yesterday, Jonathon had suggested that if I was interested in a debate about Iraq, I should focus on Steven Den Beste:

Although I don’t have any interest in discussing an invasion of Iraq on my weblog, it occurs to me Bb—if you’ll excuse the gratuitous advice—that your time might be more constructively spent debating the issues with Den Beste, who writes well, is not patronising, listens carefully, and links to opposing viewpoints.

He specifically mentions a couple of Den Beste’s postings such as one about an invasion and international lawAlan Cook suggests before I do, though, I should review the posts by Demosthenes, suggesting as a starting point this post.

First let me say that not only is my headache of yesterday not gone, it’s worse. To the point where I can’t even read Demosthenes’ white on black weblog postings. In addition, trying to follow this debate thread as it wound it’s way through several posts (with references to side material as support for specific debate points), would be nearly impossible if I was well, much less sick.

Which returns me to what is most likely a better use of my time at this point — working on my RDF book and finishing ThreadNeedle.

Categories
Semantics Standards

Up, down, charm, strange, top, bottom

Recovered from the Wayback Machine.

The markup folks are going to be the weblogging death of me yet. It’s a variation on the classic differences between the back-end or server-side developer and the front-end designer/developer.

All front-end folks know that we back-end folks are slobs when it comes to proper markup, clean web pages, and so on. And all back-end folks know that the front-end people are anal (in the nicest possible way of course). And for a client, this is the perfect combination – the back-end folks should focus on their area of expertise – back-end development – and leave the front-end to the experts.

Of course, when a back-end developer has a weblog, then all you see is sloppy markup, improper use of tags, and so on. I know. Bad Me.

(Still, I know of a front-end person or two who has needed my help for back-end issues, but we won’t quibble over that, will we?)

I know I’m a markup slob, a hopeless case if there was one. However, in recent discussions, I’m left unsure if what I’m doing is “wrong” from a technical viewpoint, or only “wrong” from an esthetic viewpoint. In particular, I’ve been reading Dorothea’s and Jonathon’s weblogs about CSS style sheets, markup, use of bold for hypertext links and so on.

Am I wrong in my use of markup? Or is this a case of pure esthetic differences? Am I a slob? Or is Jonathon, as an example, being an effete snob (saying this in the nicest possible way, of course)?

For instance, there’s the sweeping statement that underline for hypertext links is ugly. Well, ugly or not, the underline has been used to designate hypertext links since the dawn of web time. And underline is still used, by default, to mark links.

In some of my web sites, I use bold to mark hypertext links; in others, such as this weblog, I use underline within the content, bold in the sidebars. I will admit the bold un-underlined hypertext links within the content is elegant and tasteful. However, though ugly, there’s no accessibility issue or problem with using underlines within the posting, is there?

(Side question: what’s with the blue/gray in all the weblogs lately? Is this a civil war thing?)

Today, another issue arose about emphasis and the strong, em, b, and i elements. Jonathon asked the question of Dorothea about the proper use of the <strong>, <em>, <b>, <i> tags. In response, Dorothea provided a very, very nice discussion of the history, purpose, use of these particular tags.

From Dorothea’s response, I believe I am using the strong element correctly. I use it when I want to bold something – when I want to make it more noticeable, to stand out, to strongly emphasis a point, a line, a statement. I tend to use the em element to emphasis something that I don’t want to stand out if a person does a quick sweep of the eye down the page.

However, I use the strong element specifically because it is bold, and the em element because it does result in italic text. I never use <b> or <i>. Though the result is correct, is my underlying behavior incorrect? What happens in this mix when a blind person reads the page?

Sigh. At this point, I am faced with two choices: I can spend all my time fretting on these issues; or I can work on ThreadNeedle, accept the fact that I’m a hopeless web page slob who will never have an elegant weblog page, and hope that folks like Dorothea and Jonathon will specifically let me know when I’m doing something that makes my material inaccessible, or makes it break within a browser.

Categories
RDF

Discussion thread

Recovered from the Wayback Machine.

Working on ThreadNeedle’s vocabulary tonight. One additional level of sophistication could be to record a posts entire parentage within the RDF

e.g.

a – b – c
– x – f – g

The “path” to ‘g’ would be:

a – x – f – g

This isn’t complete discussion, but is complete thread.

Nested data such as this isn’t trivial within RDF, but doable. First case of a simple RDF file at http://weblog.burningbird.net/threadreplies.rdf. By using bagID, I should be able to encapsulate each level into a single reified statement that allows each nested level of blogging reply to be processed individually; the bagID prevents recursive looping back on the property. However, the complexity is increased. True, the generating and parsing of the RDF is automated, but I don’t want to add unnecessary CPU cycles to the apps.

RDF people in audience – comments? Am I cracked on this one?

As an aside, line breaks generated by blogging tools are a pain in the butt. HTML break annotation is added to the RDF, which breaks the RDF processors. The only way to avoid this is to have users add their own line breaks (and won’t that go over big); or to generate the RDF to be copied and pasted as breakless content – friggen long lines. Most likely break something, and even if it doesn’t – solution is inelegant and offensive.

A better bet would be to have a tool pre-process the RDF and pull out extraneous HTML garbage. Same tool can also grab multiple RDF blocks within same document – something many of the RDF tools don’t like. Unfortunately, this puts burden on those building tools to process ThreadNeedle data directly from files.

No solution yet to the problem of how to distribute RDF so that no dependency exists on ThreadNeedle. Or I should say, no solution yet as to how to track the distributed bits of the discussion within several different weblog postings without reliance on ThreadNeedle. This isn’t necessary to first release of ThreadNeedle – but bothers me nonetheless.

(I desperately need DSL – this work over a modem is slow torture.)

Categories
RDF

Threadneedle test RDF

I’ve posted examples of the RDF used for ThreadNeedle to the ThreadNeedle Discussion Group. One file represents the type of RDF embedded within a posting for a threading disucssion start, one file represents the type of RDF embedded for a reply.

I’ve also registered the domain threadneedle.org, and will move my work there as soon as the DNS change propagates through the system.

I won’t be moving ThreadNeedle source code to Source Forge until I have minimum functionality – Source Forge projects proceed more effectively if given a code base. Regardless, the Source Forge project will point back to ThreadNeedle as home base.

Still working through whether to implement the first draft of the tool in Perl or Java. Most likely I’ll implement both to start (and possibly Python – hmmm). And the data store will be MySQL.