MEETING NOTES November 26, 2002
- Decisions:
- Ivanhoe development should be governed by principles of simplicity. What that means? Apparent simplicity of use/concept and levels of difficulty introduced incrementally. How simple a blog-type adaptation could we build/use on existing open-source infrastructure and achieve functionality?
- Between January and July the goal is to create a whole series of experiments/iterations of such "simple" versions so they can be tested, critiqued, redesigned in rapid succession without heavy investment in info architecture/structure. Goal? By July: a plan for production that includes conceptual and technical parameters worked through on the basis of these experimental models.
Not everyone present will agree that those WERE our decisions. However, I am the scribe. I will duly record objections/reactions in our meeting on Tuesday.
NOTES:
McGann: Notes on Building an Initial Model (Document) Three basic spaces
Beth: Corollary functions suggest that all spaces should be navigable
JJM: Put aside a space to look at what is happening as a separable thing
A: Or, just invoke different views from one space
B: Or do linking, deleting, etc. in the same space unified. Part of the problem of earlier models separation of static editing/input and any imagination of how these things might look. Try to collapse as much as possible.
W: Motivations and goals.
J: Simple software that works.
W: Pedagogical or something
B: Collaborative or competitive?
J: Build on other sophistications as desired. Back to elementary state of the game.
W: Motivational statement.
J: Simple, elementary functional design
JD: But the "apparent" simplicity of a codex/screen that unfolds into its potentialities/levels.
Be: Jerry wants to make a ball, let play begin.
JM: Build a simple thing, what it can be, do, prepare for second instantiation.
A: Even in its simplicity it has to reflect the agenda we have. Keep that agenda on the front page.
JM: Not even useful to put these discussions in at this point until we begin to build this. As for instance b/c collapse some display windows shouldn't be able to be intervened in. As 'current state of certain play'.
B: Still want to have a "self" position, not necessarily edit, but navigation capabilities.
W: Decisions about how these display spaces are used.
JM: Too complicated if we allow moves to be made in the game. Back to the book/codex flexibility it allows individuals. Connections are made by individual. Licensed in a free way.
JD: Undetermined condition of the codex. But the Thorny/Daniel distinction in attitude towards documents raises questions about electronic instruments.
W: Boundaries of the codex we don't think about when we actually use it. Reordering is not trivial. Reordering by reading but not at the level of the object. Once committed, the flexibility into question still cumbersome to read in electronic environment.
JM: Making explicit that a book's pages might be re-ordered in any number of ways. Makes you realize the power of the book how much more powerful by having that constraint. Other systems for echoing/connecting. Anyone can make a set of readings. Cortazar stuff done for you and it is boring.
JD: How to do this? Story board.
JM: Pick one of the blogger things and start modifying it.
B: Picked Gray Matter and modified.
A: Is there a blogger engine that allows you to export data in a structured format.
B: My SQL Moveable Type.
A: Visualization software use SQL or export as XML.
B: Gray Matter took so little time to work with. Open source.
A: Topic maps may still be useful can create one out of My SQL data base. Could deal with the problem of units. Point in a text and span in a text. Back to an XML document as a source text that is never edited, markers in a data stream (never touched) abstract but powerful could tie to a point or to a span.
JM: How stable?
A: Keep the system intact, unchanged.
JM: A document in a stand-off markup mode of total stability.
A: Data base stores the source text (read only) nothing ever inserted into the text, topic maps.
Be: Nuts and bolts, XML text never changed, bite markers never change, how would changed paragraphs be put in.
B: Levels of control/modification. Always check for what's linked to what. Position in source text. Reference to something linked to the source text.
JM: How to output? What do we see? (JD enters document: Lucretius)
A: Astronomy text visualization towards middle ground. .
B: Moveable type categorize your entries as you enter them.
W: Stand-off markup tends to create problems on the move creation side, back to the naming problem/lexia unit problem. How to have someone tell you they want to deal with "that" thing system able to deal with that chunk. Way you give someone a way to deal with it is a problem.
A: Point or span.
B: Instead of text file, page image of original document? Link to margin, ornament etc. If what you are doing is not modifying a text document but referring to a place on an object?
JM: Pixel structure of images all numerable? Would want a mode of formalizing space/pages as images. Work with a stabilized text.
A: Towards aesthetic of a page could make the ascii text look like a page.
W: Annotation will work if you use points/closed curves can attach if you go this route.
B: Easier if you start with the text than the image.
A: Mapping for an image much more processing than a text base. If an initial use text, not image.
JM: Cost of establishing a totally stable text.
Bt: If you want to edit the text ahead of time, you could, or you could download an ascii from Project Gutenberg.
A: Can't go back and change it later.
JD: Get the most expurgated copy and build back into it.
W: Multi-valent documents from Berkeley. Pick a lens / Italian translation shows up. Some context shows up and then displays an alternative.
Bt: Image-based editing. Dante project at IATH magnifying lens.
A: Schema from the Spring not that far from stand-off mark-up all tags at start of paragraph and linked to data base didn't have to implement systems that Early designs all modifications to paragraphs were XML elements at the beginning of each lexia, referred to a data base, used query content of moves not placed in the source text. In the source text were pointers. For graph vis put pointers in a data base and generated visualization. Could be a groundwork for a basic architecture. What is the current architecture? Was the final schema implemented in this way?
JM: With the resources we have here now can we do this? OR do we need other persons. Can we build this with the talent here or do we need other talent?
Bt: Think we pretty much could depending on Gray Matter.
JM: To get around the problem of time would it be possible to hire someone to work under someone's direction.
A: If we were to try to proceed with what Nathan built need someone familiar with Java in a web environment. JSP (Java Server Page) does the work calling for things etc.
Bt: Gray Matter built in Perl
Planning stage: January to July to make a recommendation for production. Sketches. Experiments. Prototype as we have it compared with Blogger.