proto-DKR : 3.0 Spec

meta-tags for blog

This one is new. It would be great to have a meta-tag system for the blogs, so that I can assign keywords to blogs where the keywords are not already in the text. This basically means more database fields for each entry I guess.

adding meta-tags
- If a word is tagged in the Hyperwords Menu-word list as one of the meta-tag categories, and it is also in the post, it should be listed in the meta-tag field at the end of the message, fx: if 'Mikhail' is in the Hyperwords Menu-word list and 'Mikhail' is in the post, 'Mikhail' should be listed after 'people:'.
- A field in the blog admin 'posts management' page.
- When posting a blog entry. The user can add a line of text, fx: '---meta:' followed by keywords separated by commas or categories followed by colon (fx: 'location: London. people: Ted. DKR) where full stops indicate separation of categories..
- When reading a blog post. The blog will have the word 'meta:' with any meta-tags listed. There will be a + for adding and a - for removing meta-tags. When clicked, the browser will launch the users email application, much like when clicking 'comment'. + will add and when clicking the - any meta tags entered will remove any identical meta-tags in the system already for that entry. This will only work if the person clicking the = or - is the same as the original poster, as verified by the email account.

meta-tag categories
- Location.
- People.
- Primary topics.
- Category.
- Relationship: Supporting, disagree.

rtf support

This is supposed to be working, but it's not. Bold and italic needs to work.

new look for cc'd posts

Currently posts which have been cc'd (i.e. a regular email to someone which has also been blogged) looks like this:

Subject Name
Authors Name     

From: Frode Hegland
To: Paul Cairns
Cc: Ted Nelson
Date: Wed, 7 Jul 2004 17:08:54 +0100
Subject: Friday
-----------------------------------

It needs to look like this (notice not italics):

Autoblogged: Subject Name email by Authors Name     
-----------------------------------

separate calendar menu

The calendar/archive/list of posts is no longer on the side of the main blog. It's a separate page, as mocked up on cal-menu.html

Please note that when the user clicks the 'calendar' link in the blog, as shown on blog-3-layout-template.html the calendar loads already scrolled down to the anchor of the topmost blog on the page of the blog-3-layout-template.html the user clicked. This is an important feature as it takes into account two important interface requirements: the menu should allow for quick and easy visual browsing and it should not remove your present context - in other words, when you get from reading a blog post and go into the menu, you should be in the same place.

One issue which was problematic here was the requirement for the quick and easy browsing. If the calendar menu just loaded by itself, each and every blog post would move the current blogs further down the list. And away from the present, which is a frequent entry point for users. Imagine this, you are reading a blog post from this week. You click on the 'calendar' link and you get the calendar loaded and lo-and-behold, it starts a year or two earlier. So to find that post a week ago, you gotta scroll down pages and pages. The solution of having the past above the screen was semi-obvious and attempted with CSS and all kinds of stuff on the blog page itself but going out to get a good overview just made more sense in the end - as blogged: you either want to read the blog posts or browse the calendar, not both. So now they have their own screens.

options are viewspecs
The options on the top of the page are exactly the same viewspecs (minus highlight etc. and date-range, though maybe we'll figure out an elegant way to add it - the ones shown/active are the ones which are useful to constrain the calendar menu list) as the user would access trough the Viewspecs link on blog-3-layout-template.html with the same viewspec settings being remembered between the calendar menu and the blog page.

The options would load partly filled in, as per the viewspecs the user was using when the page was loaded. The reverse is also true, the viewspec changes made here will also carry over to the main blog view.

layout

As on blog-3-layout-template.html

I may go on tweaking this for a while. Can you please make the page out of these separate CSS styles (in external style sheets) so that I can continuously tweak them as we go:

css styles sheets
- For the dates
- For the header.
- For the body.
- For the commands after the body.
- For a command system on the side (not yet decided. will link to 'calendar' and 'viewspecs').

layout templates

Add options for changing the CSS style and other layout features, such as the width of the text column.

url control

Make the Hyperwords Menu communicate with the blog server via the URL. This one might be easily implemented using the "Custom menu items" implementation.

posts management page shortened

Can you provide a way to split the posts management page so that I don't have to wade through 100's of messages?

rss behavior fixed

- Make the RSS behave right (one feed per blog). 

This is now done.

html control

This refers to the ability of the user to manually add parameters to the URL.

Add a parameter to show only the most recent post.

Add a parameter to see images or not.

Server side include

To allow us to have a tag in a regular HTML page (which is going through the parser, i.e. it'll be on Liquid Information.org) to automatically include the full text of, say the last blog post.

user admin pages

Users will have their own accounts with admin pages. These accounts will be auto-generated (in addition to me making it). Auto-generation works like this: when an email arrives as a comment to a blog post, the server emails the sender asking for a confirmation that this is indeed a real comment and not spam as well as details on how to access their admin page and a temporary password. Any comment which does not receive a confirmation from the poster gets deleted (after a day maybe?).

the user admin page will include
- The ability to delete posts.
- The ability to meta-tag their own posts.
- The ability to write glossary entries, which will automatically (unless the adds a huge ball of complexity) be available in the Hyperwords Menu when readers read their blog posts, under the heading of 'Authors Glossary'.

NOTES

storing information

All the information is stored in the same way, as a blog post. The difference between a blog post and a blog comment is simply that the comment is marked as a comment and it has a field stating what it is a comment on and one stating what kind of comment it is, such as 'support', 'disagree' and so on. Marking the different types is useful for later queries, such as 'show all supportive comments pointing to this post'. Resources are similarly stored and marked.

The database contains the following data, all stored as basic building block, based on what was initially only blogs, with meta-tags:
- Blog posts.
- Blog post comments.
- Resources (html form comments, with URLs pointing to external resources).

Would it be necessary to have a separate list of links Mikhail? The system should behave as though it exists, but maybe it's fast enough to look through all the records. One strong arguments in favour would be that the list of links could include links extracted from within blog posts. This way we could have queries like this when looking at a web page: 'show me what blog posts point to this page' if any.

resources

Adding resources is done through a form on a web page. The main element is the URL pointing to the resource. The user who enters the resource into the system will also be able to choose a category from a pop-up list, add keywords and select names of blog posters (anyone with a blog account) if relevant, and the user can type in free form comments to describe what the resource is.

Mikhail, since resources disappear of the web, can we import the HTML page and store it with the resource (blog) database entry? Or should the user manually copy the text of the web page into a field? What do you recommend?

Resources will also have a date pop-up, which may or may not be used, and the whole date does not need to be used either (the year could be enough). This is mainly for pointing to historical events, such as what we have in the timeline.

The main field for the resource is not the URL, it is the users descriptive comment (which would be the event, if a timeline event is referred to).

Mocked up at dkr-resoruce.html

browser features

We should use some browser specific features like Tabs when we can, to allow users to specify if they want something to come up as a new window, in a tab or in the same window. Not for now though.

user trail

It could be useful in the future to save the users trails, so that they would have 'multiple-undo' capabilites and they could refer to the trail later, like with Vannevar Bush's trails.

html page import

1) Process the whole timeline page on Invisible Revolution, -http://www.invisiblerevolution.net/timeline/engelbart-timelines.html -framed it is athttp://www.invisiblerevolution.net/timeline/timeline-w-menu-r.html- to extract every element and store them as DKR resources (one blog post essentially per item, tagged as a 'Resource' and meta-tagged for year (as we do with normal dates now, but not requiring more than the year, leaving month and day empty) and category (name of the column it's in). Each item will have to have a 'Subject' and body, just like blog data does today. The 'Subject' will be the first sentence of each item. If there is only one sentence, then the body will be empty. Many posts are links for more information, which is stored in a separate html page. It would be desirable for this information to be captured as well, and entered as body text.
2) Put the page back together again, this time using the extracted data. Each item will show only the 'Subject', with the body being available when clicked on (the whole 'Subject' text will be a link tot he body text).
3) Allow for simple views to be specified (through Hyperwords Menu would be nice, but a form at the end is also OK, or anything else for now, this is for us at this stage, not end users). This view would search the whole of the 'Resources', not just the 'Subject'.4) Give me an admin page to edit the content, in many cases I'll have to copy information between the 'Subject' and the 'body' as the first line is not always very revealing. Also, this would benefit from being quite a generic system, so that we can do it on other web pages in the future.

SPECIFIC DKR FEATURES

add resource web form

There will be a web page where users can add resources in the form of URLs. It is mocked up on dkr-resoruce.html It is the only real feature the DKR adds to the system.

version control

Over time it will be necessary to increase the functionality of version control. Currently we have the 'freeze' feature of Augment, where once a document is submitted to the Journal (HyperBlog) it cannot be changed. Any change in the Augment Journal would generate a new version number, this we have to do manually now.

"The Hyperdocument "Journal System" - an integrated library-like system where a hyperdocument message or document can be submitted using a submittal form (technically an email message form), and an automated "clerk" assigns a catalog number, stores the item, notifies recipients with a link for easy retrieval, notifies of supercessions, catalogs it for future searching, and manages document collections. Access is guaranteed when referenced by its catalog number, or "jumped to" with an appropriate link. Links within newly submitted hyperdocuments can cite any passages within any of the prior documents, and the back-link service lets the online reader of a document detect and "go examine" any passage of a subsequent document that has a link citing that passage." from Doug Engelbart's Toward High-Performance Organizations:

links

linked: types
Links will be stored and treated as their own objects, including, where relevant, with link types and indicators as to where they are point to and from.

linked: internal
It should be possible to link to any component internally (what Doug calls high resolution addressability), not just whole documents.

linked: external
URLs should be able to point to object in the DKR environment.

External systems should be able to point to any object and viewspec within the DKR environment.

"The Basic "Hyper" Characteristics - where embedded objects called links can point to any arbitrary object within the document, or within another document in a specified domain of documents - and the link can be actuated by a user or an automatic process to "go see what is at the other end," or "bring the other-end object to this location," or "execute the process identified at the other end."" from Doug Engelbart's Toward High-Performance Organizations:

linked: backlinks
It will not be enough to show where a link is pointing to, it is also useful to see where it is pointing to."Hyperdocument "Back-Link" Capability - when reading a hyperdocument online, a worker can utilize information about links from other objects within this or other hyperdocuments that point to this hyperdocument - or to designated objects or passages of interest in this hyperdocument." from Doug Engelbart's Toward High-Performance Organizations:

flexible view control

The DKR environment will allow users to see views of the information in flexible ways, choosing to see what comments by what people and so on, what Doug calls ViewSpecs: "View Control of Objects' Form, Sequence and Content - where a structured, mixed-object document may be displayed in a window according to a flexible choice of viewing options - especially by selective level clipping (outline for viewing), but also by filtering on content, by truncation or some algorithmic view that provides a more useful portrayal of structure and/or object content (including new sequences or groupings of objects that actually reside in other documents). Editing on structure or object content directly from such special views would be allowed whenever appropriate." from Doug Engelbart's Toward High-Performance Organizations:
A Strategic Role for Groupware

This means that the system will have to be structured internally.

viewspec exports
One possibly complicating factor is the saving of views in time. This would mean that if I set a ViewSpec, I should both be able to keep it dynamic as a URL for the future (todays model) and export the results, so that in the future I can, and others can, see what the viewspec produced at that time - what the view of the situation was then. If we add the export, it would be saved with a comment field, so that the person making it can describe it.

supports and maps disagreements
Comments will be stored in relation to what it is commented on.