New Account Types and data equivalency (was post TB 3.1 mailnews backend plans)

Kent James kent at
Fri Jul 16 18:40:35 UTC 2010

  I guess I'm going to have to quit saying the MoMo isn't really 
interested in new account types! Glad to see that you are thinking about 

To really get the value of an aggregated solution, we need to think 
about the issue of data equivalency when you aggregate disparate 
sources. If we don't we will end up with a mishmash of stuff that 
doesn't really make sense as an aggregate.

The OWL spec from the RDF world has thought about this some 
( with concepts of "Data Equivalency". 
To use a simple example, when is a Twitter feed coming from the same 
person as an email, or a blog posting, or someone's Exchange email 
account instead of the same person's home account? I'm not proposing 
that we re-RDFify mailnews (still hate that name 'mailnews' by the way), 
but we should not let our reaction to the RDF debacle prevent us from 
learning something from them.

Looking even further ahead, one of the Big Ideas for Gigabird should be 
a robust way to combine together disparate data sources in useful ways. 
"Show me everything that idiot rkent said today so that I can rebut his 
ramblings everywhere" might be a sample use case. How will we accomplish 
this? We do it badly now, my address book usually has many entries for 
the same person.

It applies much further than simply contacts. Items have many different 
times, many different categories. Is a twitter # search field like 
#moz10 more like a tag, or more like a folder? For that matter, is a tag 
really any different than a folder?

It would help to start if we would define the basic model of what we 
are. For example: "Mailnews provides an aggregate view of data that can 
be represented as individual items in a tree of categories (aka 
folders), with metadata for each item that includes at least a text 
summary (aka subject) and body (which could be the expansion of the link 
in a twitter message)." If we could define the basic underlying model of 
out items, and how they are extended and aggregated, we could go a long 
way toward defining the data model that Gigabird needs to succeed.


More information about the tb-planning mailing list