User talk:Sj/coralline: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
: ''relevant to #indieweb frameworks for separating communication from specific gardens.''
#indieweb


Consider a self-identified group G of collaborators, working on a complex project.
Consider a self-identified group G of collaborators, working on a complex project.
: ''this means we have an environment containing terms denoting a channel to and an 'authorship tag' for each collaborator.''
: ''this means we have an environment containing terms denoting a channel to and an 'authorship tag' for each collaborator.''


A "''coralline''" system should support:
We would like to support, among other things:
* Defining an important topic for discussion, before deciding where it will be discussed.
* Defining an important topic or category for discussion, independent from deciding where it will be discussed.
* Publishing a message, independent from where it is published and which threads it is attached to
* Preferred ways / formats to receive full notice or summaries of topics, for each collaborator. (some people want to receive messages as they are sent. Some want summaries every so often. Some want threads to gather in a place where they can be pulled. Some want thread summaries to be queued up every few weeks during a focused period of real-time discussion.)
*: For instance: allowing publishing messages or topics across multiple groups G, H, I, &c.
* Defining topic types such that when a new thread about an essential type is started, it requires input from every one in G, or a quorum of members. Defining workflows / patterns of communication around a topic so that if an essential topic has been around for more than a week, and has not received sufficient input, there is automatic followup.

* Per-collaborator preferences for ways / formats to receive full notices or summaries of topics. (some people want to receive messages as they are sent. Some want summaries every so often. Some want threads to gather in a place where they can be pulled. Some want thread summaries to be queued up every few weeks during a focused period of real-time discussion.)

* Defining topic types (generic to specific, offhand to essential) in the context of G.
*: For instance, when a new thread about an essential topic is started, it could require input from every collaborator in G, or a quorum of members.
* Defining workflows / patterns of communication around a topic that include automatic followups and summaries.
*: For instance, if an essential topic has been around for more than a week, and has not received sufficient input, the topic could be set to generate automatic followup.



== Related concepts ==
== Related concepts ==
Line 38: Line 46:


Tasks to make this possible:
Tasks to make this possible:
* identify a namespace map for every major source of data/messages/entries
# identify a namespace map for every major source of data/messages/entries
# bootstrap a coralline interface by building it on top of an existing message platform
* use something like y!pipes to organize views
* use something like Freebase to visualize, normalize & clean, and update entries
# use something like y!pipes to organize views
# use something like Freebase to visualize, normalize & clean, and update entries





Latest revision as of 18:51, 10 September 2014

relevant to #indieweb frameworks for separating communication from specific gardens.

Consider a self-identified group G of collaborators, working on a complex project.

this means we have an environment containing terms denoting a channel to and an 'authorship tag' for each collaborator.

A "coralline" system should support:

  • Defining an important topic or category for discussion, independent from deciding where it will be discussed.
  • Publishing a message, independent from where it is published and which threads it is attached to
    For instance: allowing publishing messages or topics across multiple groups G, H, I, &c.
  • Per-collaborator preferences for ways / formats to receive full notices or summaries of topics. (some people want to receive messages as they are sent. Some want summaries every so often. Some want threads to gather in a place where they can be pulled. Some want thread summaries to be queued up every few weeks during a focused period of real-time discussion.)
  • Defining topic types (generic to specific, offhand to essential) in the context of G.
    For instance, when a new thread about an essential topic is started, it could require input from every collaborator in G, or a quorum of members.
  • Defining workflows / patterns of communication around a topic that include automatic followups and summaries.
    For instance, if an essential topic has been around for more than a week, and has not received sufficient input, the topic could be set to generate automatic followup.


Related concepts

write once, publish everywhere
let a single entry/essay have variations of different styles and lengths, each of which can be distributed with programmatic but different tags.
find everywhere, read once
allow for personal customizations that let readers determine how they want to see / view the constellation of results they get when looking for updates / entries matching a query.


Coralline record keeping

We want a high-level distributed database with a record for every piece of information or data, entry or note(as above), stream element (as from a flickr feed or lifestream), element or file (as from a filesystem), or event (from various logs and monitors).

A common shared data-struct might look like this:

  • uuniqueid (hidden)
  • name (locally unique, editable)
  • type (user-defined)
  • date created
  • date uploaded
  • creator (primary)
  • short-desc (subject / long-name / 128-char summary)
  • body text & media
  • attached entries
  • version of (parallel to | derived from)
  • related entries (similar, linked, derived to?)

Every type would have its own secondary table of data. So for instance, the 'body text' of an email would include the headers; the secondary table for type=email would include a field for every element of a mail-header.

An email with embedded images and some attachments might have the images in the body and the attachments a their own items linked as 'related'...

Tasks to make this possible:

  1. identify a namespace map for every major source of data/messages/entries
  2. bootstrap a coralline interface by building it on top of an existing message platform
  3. use something like y!pipes to organize views
  4. use something like Freebase to visualize, normalize & clean, and update entries