History and Future of Talk Digger

Frederick Giasson

Talk Digger is now 3 months old and many things changed since I had the idea to create the service and today.

I developed Talk Digger because I wanted to interrogate many search engines at once to know who was linking back to my blog. I wanted to create that application to save time and being able to quickly know who was talking about my writings and being able to contact them as soon as possible.

Then I choose to put the service publicly available to anyone, like me, that could benefit by using it. The answer has been instant: thousands of people used it less then a week after it have been publicly available. Some people even talked about a buzz.

This inflow of new users, with their comments, suggestions and questions, helped me to find new ways to use and implement Talk Digger. Then the concept of Talk Digger as a tool that help people to search for a conversation that is evolving around a specific URL is born. New ways to use Talk Digger have been developed such the bookmarklet, the creation of RSS web feeds populated with Talk Digger search results, and finally the creation of a link that a blogger or a webmaster can put on his web page to redirect their users to Talk Digger with a specific URL they predefined. Some usability features have also been developed during that time.

All these things have been developed, implemented and debugged during the first online month of Talk Digger. However, what happened during the last two months? Some people probably noticed that nothing really changed since two months, and they are right: nothing really changed; I only fixed bugs.

So, what is happening? Is Talk Digger service development stopped? On ice? Or even dead?

Definitely not!

Right, the development of Talk Digger in the last two months have been marginal, however it growth exponentially. In the last two months a worked with a client to implement Talk Digger in one of their product that permit them to use all the power of Talk Digger into their software. I will talk about it further when the new version of that software will be available, in the next week or two. This contract took most of my time in the last two months.

Then, why the development of Talk Digger growth exponentially? Because since the beginning of Talk Digger I am thinking about how I could develop the basic idea behind Talk Digger: “a social tool that helps people to find and follow conversations that evolve around a specific URL” even further. Since then, many ideas poped-up in my mind, most of them have been investigated, and some of them are on the way to be developed and implemented in Talk Digger.

The future of Talk Digger, for the next months, is simple: making the basic idea evolving in such a way that Talk Digger will be a social tool of choice to find, follow and analyze conversations evolving on the Internet.

People are talking about Web 2.0; personally I am talking about the Semantic Web. I am talking about a way to see and broadcast information in such a way that any application or software agent would easily be able to analyze and use that information. I already talk about the fact that I was orienting my professional career in that way. This said, the only way to go in that direction is by trying to implement the principles into a real application that anybody could use, knowing or not what the terms semantic web, blogs, information overload, or any other technical terms, mean.

Great, but what is the next step? The next step is to upgrade the basic framework of Talk Digger. The idea I have behind the next generation of Talk Digger only want one thing: information. So the next step is to gather even more information. There are the two next things I will develop in the next couple of weeks to make it happens:

  • Returning the last 10 results of each search engines instead of the last 3.
  • Supporting even more search engines.

I hope I answered to some questions you could have with that little article on the history and future of Talk Digger. A thing is sure: Talk Digger evolved in the last two months and many things are coming for the next months.

However, this service would not be what he is right now without you, Talk Digger users, and your feedbacks, questions and suggestions. This is probably the think I like the most: discussing of Talk Digger with people that use it, and to see how they use it or how they would like to use it. So do not hesitate to contact me if you would like to talk about it or to talk about anything else, it is always a pleasure to received, read and answer your emails!

tags technorati :

Why tagging is good for the future of the semantic web? A behavior learning perspective.

Frederick Giasson

Tagging is everywhere. People tags blog posts, pictures, emails, or any other type of digital documents. I already wrote about tagging, and some doubts I had vis-à-vis the social tagging and where tagging principles could be useful to be implemented.

However, what I would like to talk about here is the behavior of tagging. Everywhere people have to tags things, any things. People have to think about how they will classify an entity. They will think about the best words that would semantically describe a given digital document. The best thing that tagging can bring is the “classification of documents described by semantically related keywords” behavior of the Internet users.

As I talked in that post, there are two ways to create an ontology for the semantic web: collaboratively or non-collaboratively. The easiest and less expensive way to create an ontology is definitely by collaboration. However, who say collaboration, usually say anybody that has a personal computer and an Internet access can collaborate to it. Without any knowledge and practice of describing semantically an entity, the ontologies would be near useless considering that anybody could describe anything by anything.

It is why the learned behavior of tagging is essential for the future development of collaborative ontologies development. If that skill is not globally learned (at least for the people that would describe something in an ontology) resulting ontologies would be worthless and even destructive for the semantic web.

tags technorati :

Review of Foundations of Ajax

Frederick Giasson

Ajax interactive interface techniques are a spreading everywhere since the arrival of web applications like Google Suggest, Google Maps, GMail and many other high profiled web applications. It is even truer considering that Ajax techniques are intimately bounded with the most popular Web 2.0 applications.

Despite the fact that the term is used everywhere and that more and more web developers are using its techniques, Ajax remain mysterious and his techniques misused and sometime obscure. Dedicated web sites to Ajax’s development are opening and people start to standardize its development techniques and deployment.

If you start checking how to develop Ajax applications, and think that Ajax is a Greco legendary warrior, you will probably be lost in all the paths you searches will lead you. It is not an easy task, at first, to know what Ajax is and is not. Many web technologies are implied in Ajax application development like: JavaScript, XML, server-side programming languages, many different browser technologies, etc. Trying to make some order in all this information is a daunting task.

Mrs. Parker of Apress contacted me last week to ask me if I would like to review one of their new books: Foundations of Ajax. Considering what I said before on current state of Ajax development techniques’ documentation, I naturally said yes. I would had like to read that book before starting to develop Talk Digger, the Ajax interface’s development pain would had been greatly diminished. My goal by reviewing this book is: helping you to find the right tools and techniques to start on the right foot when developing web interfaces using Ajax techniques.

To whom the book is intended?

The book is intended to intermediate and expert web developers. The premise of the authors is that you already developed and implemented web sites and applications. They will not spend time to teach you what a server-side programming language is or how to create a function in JavaScript; they will teach you what are the best Ajax techniques and the available tools.

Where Ajax came from?

The first chapter is dedicated to the history of Ajax: where it came from and what motivated the development of technologies supporting it. The history of Ajax is the history of the evolution of web applications: CGI, Applets, Java, Netscape, the browsers war, servlets, server-side programming languages, Flash, DOM, DHTML, XML, etc.

How Ajax emerged from this evolution line? How should I use it? What do I need to know prior starting to develop Ajax applications? What do I need take into consideration when starting the design of my next Ajax application? All these questions will be clearly answered by the authors.

I want asynchronism

The most important feature of Ajax techniques is the possibility given to a web browser to asynchronously interact with a web server using an object called XMLHttpRequest. What it is all about? Which possibilities this object gives you? How could you use it to enhance the usability of you web site?

Then, what do I do with that information?

Once you mastered the asynchronous interaction between your application and a web server, you have to master the techniques to dynamically change the content of a web page. You have to take the received information and display it to the user by changing the DOM document of the web page. The authors will explain how a DOM document works and how to modify them to make a web page dynamics.

Many basic Ajax techniques used on popular websites are then explained: how to validate code, how to create an auto-refreshing web page, how to display a progress bar, how to create tooltips, how to automatically update a webpage, how to access a web-service, and how to create an auto-completion combo-box.

At that point you have all the knowledge necessary to create Ajax applications. The only other thing will you need is imagination and creativity to make all these things interacting together in such a way that people will say: ‘Wow!’ when they will use your interface.

I learned how to develop Ajax applications – now what are the tools that can help me to develop web applications with Ajax techniques?

Any developer wants a development environment with the best development tools. They want these tools to help them to quickly write better code. This is the exact purpose of the second part of the book: creating a toolbox for Ajax developers. The authors will describe the best available tools, what they are used for, and what is the best way to use them to develop Ajax applications.

You will find tools to write documentation on your JavaScript scripts, to validate the content of your HTML files, to inspect your DOM documents, and to compress and obfuscate your JavaScript code.

A whole chapter is dedicated on JSUnit: a unit-testing program for JavaScript. They explain how to install and use it. You think that you are losing your time implementing unit tests into your applications? Well, it depends on the length and complexity of the project you are working on. However, more often then not, you will save a lot of time on the long run. It helps you to validate that the new changes you do in one script do not affect any other functionalities of your web application before putting the modification online. Do not forget, we are talking about a web application: as soon as you save it on the web server the modifications are took into account by all users.

Finally, what would be a developer’s toolbox without debugging capabilities? Nothing. JavaScript debuggers for both FireFox and Internet Explorer are described at length.

Conclusion

What I liked while reading this book is that the authors tell you the truth about the current state of Ajax applications’ developing. Technologies that support Ajax are old, but their interactions are young. I expected, and always expect, various programming errors and problems on many web browsers while developing Talk Digger or Lektora. Many times you have to use some programming tricks to make it works the same way on all the available browsers on the market. I can’t hide it to you: it is sometime a real pain. The authors are aware of that situation and tell it to you without reserve.

This is a definitive book for web developers having to spring into Ajax’s application development world. It will show you the most effective programming techniques, tips, and tricks to create interactive web pages. It will explain you how to use the best free available tools to create your Ajax developer’s toolbox. It is an interesting reading striped of any fluff with an incalculable number of illustrations and examples.

tags technorati :

Wikipedia as a collaborative editing-ontology tool

Frederick Giasson

Introduction: ontologies

Tim Berners-Lee have a dream: the creation of a semantic web. One of the issue of with that dream is that it rely on various and well-defined ontologies. All the power of the semantic web resides in these ontologies. The current question is: how could we create such ontologies: ontologies that would describe, semantically, the world that we are living in?

Creating ontologies

Two choices are offered to us when comes the time to create ontologies:

  1. Manual creation by humans
  2. Automatic creation by documents analysis softwares

The problem with the second method is that we do not have the document analysis methods and technologies to automatically create complete and well-defined ontologies. The best we can current do with these softwares is what we could call lightweight-ontologies or associative semantic networks[1]. This is a good base to start with, but clearly not enough evoluate to make the semantic web a reality.

Manual ontologies creation

At that time, the best way to create completes and well-defined ontologies is to write them manually. Two types of manual creation of ontologies exists:

  1. Non-Collaborative
  2. Collaborative

A non-collaborative ontology is created by an expert or a small group of experts; only he/them will be able to change and update the ontology in the future. Some issues exists with that ontology creation method:

  • The availability of the expert(s)
  • The price related with he/them
  • The possibility that the expert create a part of the ontology with his believes on a subject that are not accepted by the community

A non-collaborative ontology is created and updated by a larger group of people. In fact, such ontology will normally be created on the Internet, edited and maintained with collaborative ontologies editing tools, and shared and open to anyone who would like to change/expend it. Some issues also exists with that ontology creation method:

  • The availability of easy-to-use collaborative ontology-editing tools
  • How should we handle the open issues where people do not agree on
  • Should these ontologies be centralized or distributed?

Wikipedia as a collaborative ontology-editing tool

A new type of web site emerged in the past years on the Internet: Wikis. A wiki is a collaborative web-page editing tool. It enables people to create collective works like Wikipedia.

If we check at the evolution of Wikipedia [a collective encyclopedia] in the past years, we can clearly see that people are willing to take of their time to write about various subjects, and share these writings with the Internet’s community.

People are writing up-to-date, detailed and complete documentation on any subjects that exist in our World. The question I then ask is: why should they not be willing to create ontologies related with these subjects?

So,

We have a dream: the emergence of a semantic web
We have a problem: the creation of complete and well-defined ontologies
We have a solution: to create these ontologies with collaborative ontology-editing tools
We have a problem: we do not have such tools available
We have a partial tested solution: Wikipedia

How could Wikipedia be upgraded in such a tool?

The idea is the following: upgrading the current Wikipedia’s Wiki software to create an ontology-editing module.

That way, when people would write about a subject, they could also create an ontology related with that subject. After, other people would be able to edit, change and upgrade these ontologies.

The infrastructure is already in place and really reliable. We know that people are willing to create such things. Now what we have to do is to create such a module to implement into the current infrastructure.

What would be the utility to create such ontologies?

The utility would be that new services and new applications would be able to request and use these complete, well-defined, and reliable ontologies. It would open unimaginable possibilities in the domain of information processing. I would greatly help us to handle on of the current problem we have with the Internet: the information overload.

Technorati: | | | | | | | |

If this is the Web 2.0, then what is the Semantic Web?

Frederick Giasson

I re-read the article wrote by Tim O’reilly about: What is the Web 2.0? If this is the Web 2.0, then, what is the Semantic Web? The article talk about:

1. The Web As Platform
2. Harnessing Collective Intelligence
3. Data is the Next Intel Inside
4. End of the Software Release Cycle
5. Lightweight Programming Models
6. Rich User Experiences

Tim talks about the importance of the data in the Web 2.0. The question he asks is: Who owns the data? It is a legitimate question, but is that really a question of the Web 2.0? Possibly, but the thing is that it is already a question of the Web 1.0.

Personally, I would ask the question: How to present that information? In the recent articles and blog posts I read about the Web 2.0, people talk about the openness of data available through hundred different APIs. It is certainly a good practice to gather the right information: much better than scrapping the HTML content of web sites. However, I do not think that this is the best way, a good way for sure, but not the best.

Why people do not talk about the semantic web: a way to present information in such a way that it is partially, even fully, processable by computers? This is even more powerful than hundred different APIs, no? Why is it much more powerful? Because these same applications could talk together without caring about the APIs’ protocols. I think that we should talk about the semantic web concepts much more than APIs when we talk about the place of the Data into the Web 2.0.

If I am wrong, then what is the Semantic Web?

tags technorati :