Twine: the second impression

Thanks John Munro for referring me an invitation to test Twine. As I promised earlier, I would write a follow-up post discussing more pros and cons of this novel product. So here am I.

Review of the Goal

In the first impression of Twine, I have unfolded the goal of Twine into four aspects. Hence in this test, I would like to go over the four aspects and see whether the current beta version has reached the goal.

1) Twine produces knowledge network.

The design of Twine follows a pattern: (1) initiate a twine, (2) add items into the twine, and (3) specify tags for every item. Comparing to the standard Web-2.0 design that each item (such as a blog post, a YouTube video, or a Flickr photo) is associated with multiple tags, Twine adds an additional layer upon items that is named "twine". A twine represents a more generalized categorization over the individual topics of items.

We should not overlook this new level of knowledge abstraction represented by "twines". This design shows a significant jump forward on knowledge representation. With the standard Web-2.0 design, all tags are equally weighted. For instance, there is no weight difference between the tags "Twine" and "Web 2.0" that I have specified for this blog post. It is, however, technically difficult for machines to mine structured information out of all these evenly weighted social tags. With the new Twine design, the topics of twines weight differently from the ordinary social tags that are associated with specific items. For instance, I could have created a twine with the topic "Twine" and then I have added this blog post as an item to this twine and assigned the tag "Web 2.0" for the item. By this specification, "Web 2.0" becomes a feature that describes the topic "Twine" in contrast to a peer-to-peer social tag with respect to each other. Hence we have obtained richer, hierarchical semantics for knowledge representation based on human behaviors. This type of machine-processable hierarchical information is the basis for the coming Semantic Web.

In short, this beta version has met the baseline of creating knowledge networks by Twine.

2) The knowledge networks produced by Twine are personalized.

All the stored items in Twine are placed inside a personal space of users. Unless explicitly claimed to be public, the stored items or twines are private and can only be checked by the owner. Nova Spivack once emphasized that "in Twine, about 50% of the content is actually NOT public but rather is personal to individuals or shared in private groups." So Twine has really been designed priorly for personalized knowledge management in contrast to public knowledge share.

In the post of first impression, I have questioned that whether the personalization of knowledge networks could across the boundary of individual networks. The current beta version has not yet provided a clear answer to this question. In the beta, it is not straightforward for users to watch the topology of their individual knowledge networks. Thus it is difficult to precisely tell the communication between different knowledge networks. Radar Networks would want to resolve this issue in the future.

On the other hand, however, I would rather suggest that Radar Networks be careful on supporting knowledge sharing among varied knowledge networks. Without a solid reasoning mechanism underneath, knowledge sharing across network boundaries could significantly decreases the precision of semantic search. The difference between semantic search within a single knowledge network and semantic search across multiple knowledge networks is that the latter case requires a much better solution on data mapping while the former case may bypass this extremely difficult issue.

3) A knowledge network in Twine allows users to find, share, and organize information.

In this beta version, it seems that Twine supports only keyword-based search. The current UI design suggests that Radar Networks is working on semantics-based complex search. But the semantic search has not yet come to live. We may expect more advanced search to be added into Twine in the future.

On the issue of knowledge organization, Radar Networks claims that Twine can automatically produce tags for newly added items by parsing their titles, content, and authors. This process is a typical semantic analysis; and thus Twine is declared to be a Semantic-Web application. A problem is, however, that "it doesn't work very well," said by Marshall Kirkpatrick a month ago. Maybe both Marshall and I have expected too much from Twine at the beginning and thus we both become a little bit disappointed on the testing results of this beta version.

During my test, I have added this blog into a twine and see how Twine suggests tags for the new item. Unfortunately Twine suggests only two tags---blog and Yihong, where the first one identifies the new item is a blog and the second one is my login name at Twine. Apparently the underneath engine has done nothing on parsing the content of this blog. In order to test more, I tried to add another new item---my Web-1.0 style homepage and see whether the original mistake is caused by a Web-2.0 input. As this time, Twine suggested also only two tags---Yihong and Web-1, where the first one is my login name at Twine and the second one is my specified name for the item I just added. Again, apparently no content parsing has been done. These simple tests show that there are still many bugs in this beta version.

4) Information in a knowledge network is from people who are trusted by the owners of the knowledge network.

It seems that this beta version has been equipped with a basic mechanism of trust that allows the owners of twines to decide membership. Since the quality of knowledge networks is closely related to the degree of trust that has been implemented, we should expect more sophisticated mechanism of trust implemented in the later versions of Twine. This issue might not be so critical as the others for a beta service.

In summary, this beta version has generally met the fundamental declarations Radar Networks made originally. Is this Twine beta a Semantic-Web service now? Not yet. But it certainly leads us a correct way to the Semantic Web. In my opinion, the contribution of this Twine beta is more on an attempt to construct a semantic web than on providing the world the first semantic-web application.

Three Suggestions to Improve Twine

It is still a long way for Radar Networks to have Twine be "the first mainstream Semantic Web application". I have three suggestion for Radar Networks to improve this Twine service.

Above all, Twine should not be looked like a "del.icio.us 2.0", and indeed Twine is beyond an upgraded del.icio.us. Up to the date, however, most of the comments I have seen about Twine have addressed Twine to be a new-generation bookmarking service, or in the other words a new-generation del.icio.us. Nevertheless bookmarking is a way of using Twine, Twine is much more than bookmarking. Twine is designed to produce real knowledge networks.

A critical task for the Twine management team is to design a service of viewing and managing the topology of individual knowledge networks. A visual display of knowledge networks is necessary for Twine users to issue reasonable semantic search queries in the future (if Twine goes for this direction). Unlike del.icio.us that only supports a flat structure of tags, Twine allows hierarchical knowledge specification. It is, however, not straightforward for users to issue good semantic queries unless they can have a broad view of all items bound to a particular twine. This augmentation will eventually let Twine be out of the shadow of del.icio.us.

Second, Twine needs to learn more from Squidoo, whose motto is that "everyone's an expert on something." I have been with this motto for long time and it is part of my vision of web evolution. More importantly, I sincerely believe that this motto fits perfect to Twine.

There is a basic question Radar Networks should think of Twine: what does a twine really mean to its creator? Is a twine a garbage collector to the creator as someone has suggested in one of the comments to Marshall's post? Surely a garbage collector is not be the original plot. But the challenge is, however, that how to prevent Twine from being garbage collectors. This motto of Squidoo provides an answer.

A twine should be a place where a user can demonstrate his/her expertise on whatever something. In order to realize this goal and minimize the attempts of using Twine to be garbage collectors, Radar Networks should develop delicate algorithms for users to define the scope of a twine and to be able to clean the items inside a twine. With these functions, Twine can continuously keep users being with it and really build a well-structured semantic web based on the user practices.

The last but not the least, data portability is an issue Radar Networks must consider for Twine. Since the primary goal of Twine is to help users organize private knowledge space, Radar Networks should allow users to transport their twines to their other preferred locations such as local PCs, and also allow users to upload their locally organized twines back to the remote servers maintained by Radar Networks. This capability of data portability would extend the usage of Twine by prompting the service being not only an online resource organizer but also a resource organizer that private users themselves have fully controlled either online or offline.

Final Address

Twine is an impressive new service. Although it is not yet a true Semantic-Web application, it is a demonstration that we are moving towards Semantic Web. At present, Twine is still at its very early stage. There are still many pieces missed in the current beta version. But I am confident that Radar Networks is working on these missing issues and we can expect a much better Twine service in the future.

(You may be interested in watching the previous post in this topic, Twine: the first impression.)