Category: Semantics

Categories
HTML5 Semantics

Separating presentation from semantics

After all these years, we have finally reached the point where we’ve separated page organization from presentation, and now we’re about to embark on the same mistakes again, but this time with presentation and semantics.

I’ve been following the issues associated with the vocabindex Drupal module, including one where the person submitting the bug stated the vocabindex use of UL was incorrect. We’re supposed to, MXT writes, use definition lists rather than unordered lists for any lists of terms with associated definition.

At first glance, it does seem as if the vocabindex module is using the unordered list incorrectly. After all, look at any of my category pages (such as the one for the Semantic Web)—what you see is a list of “terms” and their associated definitions. An obvious candidate for definitions lists.

Look more closely, though. In my sidebar menu I list the vocabindex terms as links to web page URIs, but there is no definition attached to any item. The description, if one is given, is, instead, added as a title attribute to the item and displayed only when the item has cursor focus. Yet, it’s the same data. Does this mean, then, I’m somehow not properly displaying my menu items? Should I have a huge sidebar, with the item description given underneath?

More importantly, whether I have a given text description for each item is purely optional, some do, some don’t. Yet the items in the list have meaning without any associated description. In fact, each item in the list is really nothing more than a label for a bucket to hold content. I could just as easily use foo, bar, silly, putty as labels, except that I’m trying to use “meaningful” labels in order to enable you all to better find past content.

In the absolutely ancient W3C page where lists are covered a list of ingredients is given as an example of an unordered list:

  • 1 cup sugar
  • 1 cup oil
  • 2 cups flour

However, I don’t see that anyone would have a problem with adding parenthetical information to this list in order to further clarify the items:

  • 1 cup sugar (light brown granulated by C & H)
  • 1 cup oil (canola or corn, but not olive)
  • 2 cups flour (white or mixed white and whole wheat)

This is really nothing more than what the vocabindex is doing with the vocabulary index terms within both the index pages and my sidebar menu: a listing of items and a (parenthetical) description to clarify what that item is. However, it’s only when the description is displayed as a “tooltip” that one sees the item as a clarification phrase, only. When presented in the index pages, it “looks” like a definition list, and so we want to have it marked up this way— mixing up semantics and presentation.

A definition list is assumed to have two pieces of information; the term or phrase and an associated definition. Even when not present, the definition is still assumed to be forthcoming at some point— not having it is the exception, not the rule. An unordered list is just that: a list of items. They can be a list of items to buy at the store, select from in a form, or click on in a web page. There’s no assumption that any additional information is necessary for the item. If there was, Drupal would make this information mandatory rather than optional. The application and associated developers would definitely discourage the use of the items in a tag cloud or other format where only the term is given because the term, by itself, would be meaningless.

Yet we look at how the terms are portrayed in a page like the vocabindex page I linked above, and that’s enough for us to say we should use one form of markup over another because it’s more “semantical”. Further exploration online at other sites who attempt to define the differences between unordered lists and definition lists shows the same thing: if we see two pieces of data, we’re assuming a definition list, because that’s what it looks like—not what it is.

The HTML5 document adds another key element to the discussion of definition lists by stating that definition lists are name-value pairs. From this can we deduce, then, that the name has no meaning without the value. That’s my interpretation: that a definition list is the proper semantic markup only when data is defined within a context of names and associated values, both of which are meaningless without the other. If, however, *HTML5 allows us to list the names without values, or the values without the names, then the HTML5 document is imprecise, and we should just use whatever we want to use— semantics can not be derived from imprecision.

Currently, in Drupal, vocabulary terms are discrete labels, nothing more. Any description is for clarification not definition, and isn’t essential to the meaning of the term. Forget how the vocabindex pages “look”, and focus on what the data means. If we can’t do that, then this whole semantic markup thing is a bit of a farce, really.

*Confirmed: it doesn’t

Categories
RDF Social Media Technology Weblogging

Creating social networks few want

Recovered from the Wayback Machine.

There has been considerable discussion this week on Techmeme about weblogging tool as social networking platform, based on Six Apart’s release of Movable Type Pro 4.2. The announcement was still wet from its birth when the WordPress folks started touting BuddyPress, a variation of social networking based on WordPress.

Among the social networking requirements for a weblogging tool are:

  • Support for FriendFeed and other feed aggregation
  • Support for Twitter
  • Forum support
  • Creating user accounts, with profiles and avatars
  • Enabling community-driven content
  • Content voting, ala Digg

I waited for the Drupal folks to tick off each of these, as this type of behavior is already built into Drupal, or provided via plug-in. For instance, support for the just given list can be met by Drupal via the following:

  • Aggregation support is a module included with the Drupal installation. In addition, the FriendFeed Drupal module provides two-way FriendFeed communication.
  • Ditto with the Twitter Drupal Module
  • Forum support is another module included with the Drupal installation, though it doesn’t have a traditional forum look and feel. The upcoming Advanced Forum module supposedly provides the missing pieces for a standalone forum.
  • All of the user functionality is also built-in, or provided as installation module, including adding users, profiles (with avatars), as well as being able to create user profiles with differing permissions. For instance, registered users to this site who I know are given a “Trusted user role” wherein they can post comments without the comment going into moderation. I could also allow users to post photos, in addition to posts of their own — it’s all role-based.
  • You can use the Voting API module with Drupal for content voting, and there have been other efforts to create a Digg-like functionality, though there just doesn’t seem to be much interest in this within the Drupal community.

In fact, Drupal began its life as a bulletin-board system, adding weblogging functionality at a latter time. It is “community-based” from the ground up. Knowing all of these, I watched Planet Drupal for someone to mention about all of this already existing capability in Drupal. And I watched. And I watched.

Nothing. Not a word. Oh, there may be those who are in the process of writing about Drupal’s capability, as compared with the new Movable Type/Wordpress initiatives, but the interest has been more about the upcoming DrupalCon, upgrading to the newest releases, and various other activities; providing yet another demonstration of the differences in communities surrounding Silicon Valley based applications, and an application with beginnings not only outside California, but also outside the United States. Differences that not only don’t include that sense of competition that seems to exist with both MT and WordPress, but that also represent a general lack of interest in becoming part of whatever new movement is currently deemed to be it. it for the moment, that is.

(A difference I’ve not, yet, come to absorb, being still imbued with the vestigial impulse to validate my choice of tools by pointing out We are first! We are better!, and hence, my earlier paragraphs. )

However, to be fair to the vast majority of MT and WP users, there isn’t that much communication in the general WordPress or MT communities, either, about the newest social networking “needs” that seem to be the driving force behind these new tool developments. Regardless of tools used, I find it unlikely that most people are interested in much of the social networking capability that is now being touted as “necessary”.

In her post at ReadWriteWeb related to the release of the new version of MT, Sarah Perez asks, Is this the future of blogging? Or is this the future of web publishing altogether? I think we’ll find, ultimately that the answer is no. The Silicon Valley mindset, for wont of a better term, wants social networks, and assumes the rest of must want the same thing. However, I think we’ll find that most of us just want a web that’s both open and accessible, and there is a vast difference between an open web and a social network.

In an open web, we may try to annotate our writings with metadata, so that the information described in this metadata could be merged by other applications. We work to ensure our work is easily accessible, and (though not always), try to engage our readers. We hope that the site is viewable by a variety of devices. To facilitate these interests, we’ve added syndication feeds and comments, some use of microformats, semantic markup, and even, on rare occasion, RDF, and perhaps a feed aggregator or photo feed in the sidebar. We try to create valid web pages, and use CSS to add a little of our own personality to the site’s look. At a stretch, we may include FriendFeed or Twitter postings, too, but I think interest in these is rarer than one would expect by the cacophony of noise that seems to accompany both services.

An open web, however, does not demand a web whereby the line of demarcation between the writer and the reader becomes blurred, and the reader is assumed to not only be reader, but writer, editor, and critic too— becoming one of many, which seemingly are then used to not only prove the popularity of the site, but also help monetize it.

Specifically, the success of our spaces is not a measure of noise but of satisfaction. What’s happened, though, is that to the Silicon Valley mindset, noise is a measure of satisfaction, so the more accouterments enabling noise, the better.

Posting writings and allowing comments are not enough: we must also give people profiles, with avatars and ranking systems, and the ability to vote comments up and down. By providing multiple levels at which our readers can engage, we create that noise that is seemingly so important in order to justify the worth of our spaces. What we’re finding, though, is that based on such activity, the noise level may increase, but it increases as noise, rather than the thoughtful comments that inspired our original interest, years ago.

As we invite the readers to become more involved, we probably will increase the popularity of our sites, but at what cost? We lose the ability to own our own spaces; to be able to suddenly switch one day from writing about HTML5 to writing about art. Even having comments means we give up some control over what we do in our spaces. All too often when I visit tech web sites and the author is writing on some other topic, I read in comments: “That’s not why I read your site, I don’t care about foo. I want to read about bar”? Or the newer complaint many of us have begun receiving since the advent of Twitter: “*This post is too long to read.”

Voting up and down may increase the number of visitors, and they may feel increasingly engaged, but look at what happens at sites like Digg. Though interesting stories may appear in the front page, such as the one about CAPTCHA technology being improved with the help of old manuscripts, many more are based on the amount of controversy associated with the topic, and not whether the topic is useful, or even relevant. More importantly, popular sites proliferate in popularity driven listings while less popular sites are pushed to the back, making it that much more difficult to find not only new and interesting information, but new and interesting sites. The reader becomes not only writer, editor, and critic, but also gatekeeper.

I’m not writing this to be critical of Six Apart’s new Movable Type social networking software, or the upcoming BuddyPress by WordPress—more power to **both groups in working to expand their offerings. To extrapolate, though, from these new offerings to a whole new web is typical of a mindset that is becoming increasingly isolated in how it views the web and how the web should be.

More importantly, to extrapolate one small group’s determination of what’s necessary in order to be “successful”, to the broader population can actively hurt rather than help the web. Do we really want a web without nooks and crannies, small voices, quiet places, and serendipitous finds? That’s not the web I want. To say that we’re all becoming increasingly narcissistic, is to say that one group’s self-obsession is shared by all, and I don’t think that’s true.

*And I include this post among those considered “too long to read”.

**But Drupal was first.

Categories
HTML5 RDF SVG

Son of Blob

Recovered from the Wayback Machine.

Adobe has decided to partner with Yahoo and Google, specifically, in order to enable search engine access to Flash contents. In other words, web builders that use bad web practices have been rewarded, and can continue to use Flash to completely build their sites, without regard for accessibility or an open web. The site designers do not have to worry their pretty little heads any longer, because the big boys have come to an “arrangement of mutual benefit”, and have decided that no, their shit does not stink.

I’d like to think that one reason Adobe is making this move is because it feels threatened from competition by SVG, but even a fangirl like myself has to acknowledge that much of this is probably related to recent moves into the animation and rich content field by other not-to-be named competitors. Besides, what chance does an open sourced, and openly accessible, technology have against such attractively packaged vendor lock-in? I mean, Google, Adobe: what more would we want?

We should just quit work on HTML5, right now. RDFa, too, not to mention microformats. Forget that semantic markup stuff, and the debate over ABBR. Who needs SVG, anyway? We have Flash, and Flash can be searched. The web has arrived.



Categories
RDF

RDF Not

I must reluctantly put away the RDF and SPARQL modules for Drupal, at least for now. Both are very new, mostly undocumented, and support seems fragmented. I’ve tried for hours to get the SPARQL endpoint to work on this site, with no luck, and not sure who to ask for clarification.

I can read the code, but much of it focuses on the Drupal development. Until I’m more familiar with Drupal, looking through the code isn’t going to be overly useful.

Once I finish the second edition of JavaScript, I can spend more time with Drupal module development and these modules. By then, more mature versions of the modules might be out, as well as some documentation in how to use the beasties.

Categories
Semantics Writing

RDF too

Congratulations to the RDFa folks for rolling out a release candidate of RDFa for XHTML. Now that I’ve finished tweaking site designs, my next step is to see about incorporating smarts into my pages, including the use of RDFa. In addition, I also want to incorporate the RDF Drupal modules more closely into the overall functionality. The SPARQL module still seems broken, but the underlying RDF modules seem to be working now.

The RDFa release candidate is timely, as I gather the BBC has decided to forgo microformats in favor of RDFa. This has re-awakened the “microformats vs. RDFa” beast, which we thought we had lulled to sleep. I guess we need to switch lullabies.

Speaking of lullabies, I had hoped to start work on the second edition of Practical RDF later this year, but it is not to be. The powers-that-be at O’Reilly aren’t comfortable with a second edition and have accepted another book proposal that covers some of what I would have covered in order to make the book livelier. There just isn’t the room for both.

I am disappointed. The first version of “Practical RDF” was difficult because the specification was undergoing change, the semantic web wasn’t generating a lot of interest, and there weren’t that many RDF-based applications available. Now, the specs are mature, we have new additions such as RDFa, increased interest in semantics, and too many applications to fit into one book. I feel as if I started a job, and now won’t be able to finish it.

One issue in the book decision is the “cool” factor. RDF and associated specifications and technologies aren’t “cool”, in that people don’t sit around at one camp or another getting hot and bothered talking about how “RDF is going to change the world!” However, the topic doesn’t necessarily have to be “cool” if the author is “cool”, and I’m not. I don’t Twit-Face-Space-Friend-Camp-Chat-Speak-Shmooze. What I do is sit here quietly in my little corner of waterlogged Missouri, try out new things, and write about them. That’s not really cool, and two not-cools do not make a hot book.

I don’t regret my choice of lifestyle, and not being “cool”. I do regret, though, leaving the “Practical RDF” job undone. Perhaps I’ll do something online with PDFs or Kindle or some such thing.