An Annotation Should Be a "Key Wavelet-Name" Pair

[GoogleCodeExporter]

Suggestion:
An annotation should be a "key wavelet-name" pair, instead of "key value" 
pair.

Background:
Soren Lassen wrote that "If you want an annotation with a complex 
structured value you have two options, either encode the value in a string 
(e.g., using JSON) or put the actual value in a data document in the 
wavelet and let the annotation value be the document id. The latter allows 
you to represent the structured value in XML and it can be edited 
concurrently as operations on the data document are subjected to 
operational transformation."
(http://groups.google.com/group/wave-
protocol/browse_thread/thread/e1f7513ec8acbc45)

And note that in order to use an access control or concurrent editting, you 
have to use a new wavelet.

Note too that "key wavelet-name"-pair annotaions do not impair any of the 
abilities that "key value"-pair annotations have.

Reasons of this suggestion:

1. You cannot identify what is the actual data in "key value"-pair 
annotations.

Since "key value"-pair annotations can contain data itself or wavelet-id 
(you may call it an 'annotation link') that indicates where the actual data 
is, only the creator of the annotation knows what is the actual data.
For example, consider that there is an annotaion which value is "wavelet-
id=111". Then, what is the actual data? Is "wavelet-id=111" ITSELF data? Or 
is the actual data contained in the wavelet whose id is 111? There is no 
common way to identify it.

This leads to another problem.

2. Users cannot edit annotations in "key value"-pair annotations, whereas 
users can edit them in "key wavelet-name"-pair annotaions.

Mainly, robots use annotations. But there should not be any difference in 
abilities in users and robots. But as stated in Reason 1, you cannot know 
what is the actual data. Therefore, you cannot edit annotations that other 
robots created. In other words, a client application cannot create a common 
way for users to edit annotations. But in "key wavelet-name"-pair 
annotaions, a client application can easily show what the data is and 
easily be editted, since data too is just a document in a wavelet.

3. "Key wavelet-name"-pair annotaions provide a consistent way for creating 
annotations.

Even though data itself is the same, if you want an access control or 
concurrent editting, you have to make a new wavelet. So depending on what 
features you want to use, there may be a difference in the way to create an 
annotation. This is not desirable. Since a wavelet has full features that a 
wave has, "key wavelet-name"-pair annotaions provide a consistent way.

Illustration:
This is not intended to explain problems, but I want to illustrate where 
this idea came.
A blip is a place where users communicate with each other. Then, what about 
robots? It is unnatural for robots to use a natural language to communicate 
with each other. So it is natural for them to use annotations. So, an 
annotation is a place where robots communicate with each other.
Some of the conversation of users can be understood by robots. For example, 
when Linky finds "http://www.xxx.com", then Linky understands that it is a 
url, but Linky does not understand other parts of the conversation. On the 
other hand, robots talk with each other in an annotation, and some of their 
conversation can be understood by users, by using javascript to display it 
in the blip.
Just like a robot can intervine with the conversation of users directly, 
users too have to have an ability to intervine with the converstion of 
robots directly in an annotation. So it is very important that the client 
application has a button to show the data of an annotation and give users 
the opportunity of editting it.
This is a way of collaboration of users and robots, I imagine.

Original issue reported on code.google.com by finitefi...@gmail.com on 1 Jul 2009 at 3:54

[GoogleCodeExporter]

I think there are two ways to solve this problem.

1. Change annotations to key-waveletname pair.
2. Make two types of annotations.
     annotation-data: key-value pair
     annotation-link: key-waveletname pair.
   If the data contained in an annotation is simple, use annotation-data. If the data 
is complicated, or you need an access control or concurrent editing, use 
annotation-
link.

Which is the better solution?

Original comment by finitefi...@gmail.com on 10 Jul 2009 at 4:49

[GoogleCodeExporter]

Original comment by btkalman@gmail.com on 29 Aug 2009 at 2:07

[GoogleCodeExporter]

Hi Toshiya, thanks for your ideas!

So if I understand correctly, you already agree that your suggestion is already 
possible with the current annotations, as the value can be a wavelet id 
and then you can store more data in another wavelet. The only problem you have 
is that it might be unclear whether the value is data, or whether it's a 
wavelet id? I will try to convince you that this is not a big problem. Data 
needs to be interpreted somehow - a robot or client needs to know what 
different tag names mean; it needs to know what the annotation keys represent, 
and how to interpret the data in any linked wavelets. One way for robots 
to understand what different XML tags, and annotation keys represent, and what 
restrictions there are on their attributes and values, is to use schema 
definitions. We already have XML schemas, and there's no reason we couldn't 
support some form of schema for annotations as well. Then you could specify 
what restrictions apply to what key types. At the end of the day, all data is 
just 1's and 0's on the wire, it's all how you interpret it.

There are also advantages in not restricting annotation values to be wavelet ids
 * There are a lot of simple annotations, such as for bold, italics styling, which only need a simple string value such as "bold". Requiring the info to 
be in a separate wavelet would be far too heavyweight
 * There are other types of things you might want to refer to, other than wavelets. Other waves, or other documents in the same wavelet, for example. The 
spelly annotations reference a data document in the same wavelet, it is not 
necessary to have an entirely new wavelet for the spelly data. (The spelly 
robot and client rendering code knows how to interpret spell annotations, to 
interpret their values as data document ids).

Original comment by daniel.d...@gmail.com on 17 Nov 2009 at 12:55

[GoogleCodeExporter]

Thank you for your explanation, Daniel. I agree with that.
I did not know that Spelly refers to a data document. I cannot wait that inner 
API is 
available to all users.

Original comment by finitefi...@gmail.com on 17 Nov 2009 at 3:03

[GoogleCodeExporter]

Original comment by oh...@google.com on 21 Nov 2009 at 2:38

• Changed state: WontFix