User talk:Sj/coralline

#indieweb

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:

• identify a namespace map for every major source of data/messages/entries
• use something like y!pipes to organize views
• use something like Freebase to visualize, normalize & clean, and update entries