Categories
W3C

The whole thing

The Architecture of the World Wide Web, First Edition was just issued as a W3C recommendation. I love that title — it reminds me of Monty Python’s “The Meaning of Life”, volume one.

Interesting bit about URIs in the document. To address the ‘resource as something on the web’ as compared to ‘resource as something that can be discussed on the web’ issue, the document describes a resource thusly:

By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term “resource” is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext Web to describe Web pages, images, product catalogs, etc. as “resources”?. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as “information resources”.

This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a representation.

However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you’ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably be an approximation of the essential character of the resource.

The document then gets into URI collision:

By design, a URI identifies one resource. Using the same URI to directly identify different resources produces a URI collision. Collision often imposes a cost in communication due to the effort required to resolve ambiguities.

Suppose, for example, that one organization makes use of a URI to refer to the movie The Sting, and another organization uses the same URI to refer to a discussion forum about The Sting. To a third party, aware of both organizations, this collision creates confusion about what the URI identifies, undermining the value of the URI. If one wanted to talk about the creation date of the resource identified by the URI, for instance, it would not be clear whether this meant “when the movie was created” or “when the discussion forum about the movie was created.”

Social and technical solutions have been devised to help avoid URI collision. However, the success or failure of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications.

Categories
Diversity Standards

Accessibility and Geegaws

A good rule of thumb for web design is that indulge your interests in nifty tools–DHTML*, Flash, whatever–but your navigation should never be made up of anything other than a hypertext link, and you should never make your critical content accessible primarily (or only) through a mouse.

Lately, I’m seeing more and more sites use technologies, Flash in particular that violate these rules. As nice as they look, I always wince when I see a dependency on a specific product, focused at a specific audience: internet hip, sighted, and attracted to bright, shiny things.

Learning from DHTML

I didn’t always resist the shiny geegaws myself. When we were studying DHTML after it first came out, we all started using it to create our navigation buttons, and felt pretty cool and very web savvy. Mouse over a top-level button and a small little box would slide out underneath with all your options to click. After static content, this was heady stuff.

Of course, mouseover wasn’t always reliable. Sometimes you’d have to move quickly from the top-level to the sub-topics because leaving the top-level would close the sub-topic box; it then became a game of who could move faster–you or the browser.

This was all until we started running into cross-browser differences and the nightmare that followed for a good 2 or 3 years until Mozilla came along and routed Internet Explorer.

(What do you mean someone is still using IE?)

Then someone came along and said, well, what about blind people or people who can’t use a mouse? After all, it’s pretty difficult to try and tab through a lot of nonsense that doesn’t do anything in order to get to a working link. And if the work is DHTML, well that just mucks with the page reader’s electronic mind, and it doesn’t know what it’s dealing with.

After Google made web search fashionable and especially after it added a thing called pagerank, we found that not using hypertext links to manage our site navigation was actually working counter to seeing our pages show up in the search results, and as highly placed as possible. Pretty geegaw lost its attraction really quick on this one.

Especially when you add in the costs. In the dot-com job I had before it became dot-gone, I was brought in to lead a re-design of an application after another firm had spent close to two million dollars and basically had very little to show for it; all except for a really cool DHTML navigation system. No backend development. Half the pages needed unfinished. No database. No database design. But there were some really cool DHTML and pretty graphics.

Well, we kept what we could and yanked the DHTML and put a system out on the street in about five weeks. With plain old hypertext links.

But still, designers say when showing their latest frufrah, look how cool this all is?

(When I as at that dot-com, I shared an office with the lead web page designer — an art school grad. He was a nice guy and did the Burning Man thing and was all that was hip among designers, and very talented, too. But I still felt like I was sharing the office with someone from another galaxy, especially when it came to priorities. I know he must have felt the same way. Companies should do that more often–house the backend developers with the front-end designers. If both survive the experience, they might learn something from it.)

Let’s see: on the one hand we have cool. On the other hand we have cross-browser compatible, easier to build and maintain, search engine friendly, and accessible.

Bottom line, we came to understand that using DHTML to manage navigation, or to display critical content, was very uncool.

Next Big Thing

Of course, now we have the Next Big Thing in website design, which is Flash and its various incarnations. And it’s true, Flash can help you do some nifty stuff — but it still brings in the same burdens and problems on a page. You have to install the plugin; you have to have special readers for the content; you have to provide an alternative link structure for webbots if you want your pages search engine friendly; and it costs a lot more to design and maintain a Flash navigation system then it does plain old hypertext links.

To work around the accessibility issues one can use page readers that can read Flash, and one can install the plugins to access the navigation buttons; still each of these methods require that the web page reader go through extra effort to access your webpage content; content that supposedly you really want them to access. Site purpose and accessibility, in this case, is sacrificed to site design.

But isn’t design meant to enhance a site, not obscure it? In other words, if Flash and JavaScript hinder access, never use Flash, or JavaScript, or any moving part other than a hypertext link for site navigation–in fact any content that is critical for the site. If you must, have a separate Flash site, but make sure it’s secondary.

The Payoffs in Accessibility and avoiding the Geegaws

I’m not a web designer and I don’t pretend to make the prettiest pages and or use the best CSS and hippest styles; but one thing I have learned over the years is, if you design for those with accessibility challenges in mind, you’ll find that you’ve also created the easiest to build, easiest to maintain, cleanest, most valid, less fragile, and more forward compatible site design. In other words — designing for accessibility ends up being the best approach to designing for style, validity, durability, and economy.

*DHTML is Dynamic HTML, or using scripting language, usually JavaScript to manipulate a page’s contents after it’s been downloaded to the browser.

Categories
RDF Specs

What is FOAF and why do you need it?

I thought I would break in with a little tech talk and discuss FOAF, or Friend of a Friend. If you hang around weblogging for any length of time, you’ll probably come across this term. Might be nice to know that it’s not some kind of new goverment regulation.

FOAF is XML created using a specific RDF (Resource Description Framework) vocabulary that allows you to provide a file with information about yourself, and basically, who you know. It’s the brainchild of Dan Brickley and I believe Libby Miller, and has its own support site and blog, though I’m not sure if the weblog is still being updated.

You don’t usually make a FOAF file by hand–either it’s created for you by your tools, or you can use the FOAF-a-matic, a handy forms-based tool that generates valid FOAF XML for you. You can then copy the contents into a file, named something like foaf.rdf, and put this file into the same location as your weblog. Some weblogging tools can do this for you, and you’ll need to check with yours to see if it does, or doesn’t manage FOAF files for you.

To enable people to autodiscover your FOAF file, you can then add the following into your primarily web page, in the HEAD section:

(Note, I had to remove the example because it was not showing up in the page, even with angle brackets being escaped. This most likely is a bug with the underlying tool implementation. The link to autodiscovery also shows the code.)

To see a badly outdated version of a FOAF file, you can check out mine.

Now that you have an idea of what it is, you might be wondering what’s it good for.

Some weblogging tools use FOAF files to auto-generate blogrolls for a weblog. Some people might consider this a goodness, but I’m not one of them. The reason why is that just because you know someone doesn’t mean you want to recommend to the world that they read them.

Others build libraries of photos and friends’ photos using FOAF and it’s image capability, which could be particularly useful for managing photos across many different web sites but based on the same event.

There has been talk of using FOAF to build a Web of Trust — to be able to state who you trust in FOAF and then a person knows based on this that they can also trust them. Though there has been a great deal of work on FOAF and privacy and accountability, the vocabulary isn’t there yet, and even the creators would be hesitant about recommending FOAF as it stands now to be used for a basis of trust.

There has also been discussion about extending the FOAF vocabulary to expand the types of relationships available. However the concern on this is the impact something like this could have, if one person considers you a friend and you put into your FOAF file that they’re just someone you know. And do we really want people to know whom we love, have birthed, work for, and so on? Sometimes. Sometimes not.

However, using relationships internally in an application, something such as an address book, could be very useful — but then why use FOAF, which is primarily used to create networks based on publicly accessible FOAF files.

Regardless of use and opinions about FOAF, it is now the second most widely dessiminated example of RDF/XML in use today, after RSS 1.0. And if you hang around weblogs, you’ll be stumbling across it at one time or another. More than that, the tools you use may be asking you whether you want a FOAF file or not.

Categories
RDF Specs

Critical Mass

Recovered from the Wayback Machine.

When I read about the RDF Data organization, I was reminded that the difficulties inherent with deriving a new vocabulary and associated functionality isn’t found in the bits of XML or the bytes of code: it’s generating enough interest and uses thereof for the vocabulary to reach critical mass; making it into a viable component of the semantic web.

By critical mass, I mean that there is enough meaningful data to inspire applications that mine the data and that in turn, generate processes that couldn’t be done without the data: similar in concept to the critical mass that HTML received and the subsequent spawning of both browsers and search bots. Private or commercial applications that use RDF/XML for their internal systems are all well and good and provide needed exposure–but they aren’t a component of the semantic web if the data is not publicly available and with enough critical mass to make it useful.

You may have noticed that I used the small ’s’ and small ‘w’ semantic web; the reason is that I see the Semantic Web, the uppercase version, as a top-down approach to building an intelligent web. A bottom up approach is just us folks, doing whatever it is that interests us and gets us excited–and, I hasten to add, that can be translated into RDF/XML. For some the exciting bits would be FOAF, others RSS, others DOAP, and so on. These are the vocabularies that need a critical mass, as the Uppercase bugger has knights and other nobility to do its promotion.

My own interests in semantic web data that can be defined with OWL/RDF lies in two areas: poetry and web object history. These have been represented by my work on two systems: The RDF Poetry Finder and PostCon. Yes, the two perpetual motion systems, always in development. Both of which would meaningless in and of themselves, unless they reach critical mass.

For instance, I use PostCon to manage some of my redirects and provide intelligent responses when a page has been pulled. I’ve also generated PostCon RDF/XML files for all of my weblog entries and placed them on the server. I believe at one point, I could even semi-search them in Google, but only when I’ve linked them from my HTML pages.

As for the Poetry Finder, well I’ve tried to interest two major poetry sites in this but to no avail, and am either looking at supporting a centralized repository of data for the nonce, or trying to get webloggers to generate RDF/XML files to go with their poetry discussions. (More on this later.) A simple enough form that can generate the RDF/XML, just as with FOAF, should work. It’s getting people to use it – demonstrating an advantage. FOAF adopters adopted FOAF because they’re basically tech tinkerers. Poets are not known to be tech tinkerers.

Regarding the data jewels of others, DOAP, the brainchild of Edd Dumbill hasn’t reached critical mass yet, but should. I think the key would be incorporation into a hugely popular site like SourceForge.

The growth of RSS has reached critical mass and way beyond at this point, though the differing formats still cause confusion. It was helped with its early promotion by major companies , but the real key was it’s support by aggressive individuals who have all the zeal of a fresh missionary among bad sinners. Even if the support was for plain vanilla XML rather than semantically intelligent XML (ooo, did I say a bad thing ooo). FOAF’s growth has also reached critical mass, helped primarily by the happy and gentle persistence of it’s creators, as well as adoption by some high profile people and applications.

Both vocabularies were also helped, quite significantly, by weblogging. In fact, I see weblogging as the leading agent of change for the semantic web–the tool/technique/genre/thing most effective in helping a vocabulary reach critical mass; and I’m not even wearing any pajamas as I make this statement (sorry, bad joke). The only problem is trying to get enough of a critical mass in weblogging to be heard above the competing noise, and then enough webloggers interested to jump start the generation of the data to reach the semantic web critical mass–all without having to have the zeal of a fresh missionary among very bad sinners.

Categories
Standards

Out! Out damn standard!

Dave Shea says, like, “Chill, dudes!” about standards. Like, wow, don’t cop a tude, bizatch!

But then my homey Matt goes, Jinkies! Boo that! Bring on the 5-Oh, dude! Don’t murk my standards! Like XHTML is phat, you know? You wanna be part of my posse, you gotta say that yo XHTML is righteous, dude! Like my bluud, Jeffrey. blahhDoww beotech!

I’m giggen, and don’t mean to diss on Matt but like, the word is what matters, man? You hear that? The word is like, Poppins. Yo standards, and yo ‘we be bad, shit’.

I mean, tell it to the ass!