EpiData

Summary

"EpiData" is a term I am proposing to refer to application-related data that is displayed in-line within the body of a wiki topic. What I mean by "application-related data" is any data in a topic that derives its meaning and utility from some larger structured data framework external to the topic where it's displayed. EpiData is in the topic but not of the topic. Examples of EpiData within TWiki (and the associated data structure) include people (the Main web), attachments (attachment table), links (WikiWords, TWiki:Plugins.LinkOptionsPlugin), actions (TWiki:Plugins.ActionTrackerPlugin), calendar events (TWiki:Plugins.CalendarPlugin), annotations (TWiki:Plugins.CommentPlugin).

Why is EpiData important for TWiki?

As wikis become more complex, how EpiData is treated will become more and more important. One might think of the first generation wikis as the simple freeform "whiteboard" application. The second generation wikis have included progressively more sophisticated structured data capability. I propose that the dominant feature of 3rd generation wiki will be re-integration of the structured data into the free-form whiteboard.

The key to this will be a consistent user interface for EpiData. From a users perspective the interface for creating and referencing different EpiData should be consistent regardless of the data-structures of the various applications different EpiData draws upon.

Examples of EpiData

Examples of EpiData along with notes about current storage and interface:

• Links (internal & external)
  • WikiWords were the most basic EpiData.
  • LinkOptionPlugin (or something like that) and ToolTipPlugin are examples or how/why syntax for links needs to be expanded.
• People
  • Current implmentation:
    • Simple links to user topic. The "application" is the Main web.
  • Some of the functions people-EpiData might offer:
    • send an email to them.
    • search from them within the wiki and on the web.
    • go to their user page.
    • initiate a chat session.
• Tasks (i.e. action tracker plugin)
  • ActionTrackerPlugin (ATP) was my original inspiration for EpiData.
  • Current implementation
    • Data is stored in-line in topics with separate cache of data. (I think this is right but not really sure.)
    • Interface: pop-up window for editing content.
• Events
  • Not very fully developed in TWiki. The CalendarPlugin is part way there.
  • Full implementation would allow creation/display of events in any topic (as with ATP) and these are gathered together for display in calendars.
• Attachments
  • This is prime example where something that should be EpiData is treated (currently) as meta data for a particular topic.
  • Current implementation:
    • Attachments and associated info stored in topics' metadata. Probably not a great approach for long term.
    • Being able to attach/associate files to any topic is great. Having to remember and reference which topic a particular attachment is associated with sucks.
    • The syntax for displaying attachements in-line sucks.
• Annotations - footnotes, comments.
  • Full implementation would incorporate something like "purple numbers."
• Data from exteral db's and applications.

Note that the sources and storage structure of these different data vary greatly. But, again, from a user's perspective, that doesn't (or shouldn't) matter.

Design for Epidata

The focus here is what would be important to users in using EpiData.

User's priorities for EpiData:

• Consistency of interface for using various EpiData.
• Ease of referencing existing EpiData.
• Flexible formating for EpiData display.
• Ease of creating new Epidata.
• Degrades gracefully in plain text topic.

Further thoughts on where this might lead

-- LynnwoodBrown - 20 Apr 2005