User talk:Sj/coralline

1. 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.

We would like to support, among other things:

• Defining an important topic for discussion, before deciding where it will be discussed.
• 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.)
• 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.

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