Its been almost three years since my last post...

I think I might return to it now that Google Wave is out.

Wiki's is the only version of collaboration-ware left to integrate into it.

Its is basically N:M with any kind of objects (including any kind of media-objects) being connected to any kind of objects, but the connections all make sense.

I love the fact that its open source, anyone can contribute, though there are strict protocols for how anyone can contribute, and not top down, which is how software has been spoon-fed (and often force-fed,) to us.

I will be very interested in any visualization schemes that are created to deal with and present the complexity.

I suspect that they will be variants of my nested, topologically sorted spheres with the relationships defining the nesting and providing the visual clues of the connections that are possible between them...

It will be ... interesting. :-)

OiRc-0010 I didn't need a job THAT badly...

Last summer, (July 2006, when I actually wrote this entry, that I'm only posting in May, 2007) I walked away from a project that was fatally flawed.

I determined this before I ever sent in my first invoice so they have nothing to complain about as far as costs.

To protect myself, I will never reveal the company, the individuals involved or what the domain was. As far as you might be concerned there is/was no such company, project or people.

I will say the following, without naming names though:

The 'chief architect' had no vision. He insisted that I stop working on what he thought of as an application when it was really the visible tip of the iceberg of a complete system.

If I'd listened to him, I'd have been shoving bytes around a table (pun intended) and dealing with shite when what was possible was vastly greater.

One of the principals really 'creeped me out' with his attempt at Latin phrases, and 'inspirational' email messages. (Religiosity may be fine as a personal belief system but it does not belong in the boardroom. Decisions about scheduling must be based on truth; anything else is just "trying to saunter across a very busy multi-lane highway and hoping you won't be run over by the semi barreling down right at you." [... SPLAT! ...])

The overall system belied a general lack of understanding of the power of relationships and revealed that they just didn't 'get it.' They sort of understood, but only sort of. (I don't need to evangelize what people like the military and the NSA already know. [If they don't do it, they must have some strategic reason. {Its a smart tactic; like using night-vision goggles while the opposition is fumbling around in the dark.

(There are only five basic objects [which answer the five fundamental truths: "who, what, where, when and why."]

The rest is Relationships dealing with these objects and instances of each other, and Connections dealing with instances of these objects and instances of each other. [But each other doesn't refer to the same class of object. :-]

For some reason, probably related to the mental gymnastics of trying to deal with them, people immediately start flattening out the relationships and start creating meta-objects which they then pretend are the real objects, [not realizing that they're not and if they need to deal with them, they're going to have some major problems.])}])

The deadlines for milestones on the project deliverables were unrealistic and based on nothing more than suppositions.

Throwing more people at a project just makes it later and that's exatly what was happening. (See the "Mythical Man Month" by "Frederick P. Brooks, ISBN: 0201835959 for an exploration of an old story.)

The ultimate deliverable, and the intermediate steps to achieve it, needed to be far better described. (Otherwise it leads to staff 'burn out' and dissatisfied 'end users.')

I've been around enough to smell disaster.

I chose to discretely disappear and leave them to it.

This is the, uh, object lessons that that can be learned from this kind of project:

• Data mining doesn't need to keep track of object states because the states are considered frozen at a point in time. Hence there was no need for state transition engines in their particular project (but it would have been trivial to merge in a relationship which connected to instances of a 'perpendicular' object.)
• Merging data from several sources, (be it a database, where tables represent the data objects and the columns are described in a DBSchema, or in CSV files, where the first row contains the column names,) and joining multiple seemingly disparate schema into a cohesive whole, is really a trivial problem. The data exists. Deal with it.
  
• Coming up with a 'super schema' requires finesse and an understanding of objects and relationships.
  

Actually, this was a trivial exercise because none of my code dealt with the client, the data or the purpose. It was all meta-meta level programming which needed to be done to generate the meta level solution that was being sought.

They didn't listen, and the company doesn't exist anymore.

I don't feel sorry for them or for the solution I came up with to solve the problem they actually had (and which killed them off in short order,) rather than fighting the fog surrounding the problem.

OiRc-0009 Seeing Views intelligently (+ off-topic)

Views, in the database world, are selected snippets of table definitions and SQL which may be used to retrieve some tables' rows and any, uh, related, table rows (by foreign keys and/or through the execution of the SQL associated with the view) into a new table with its columns filled by the retrived rows.

The problem with views is that its is hard to know exactly what is being retrieved or from where.

For retrieval, this is sort of excusable.

Human beings seem to possess an almost infinite capacity for stomping all over objects and relationships, flattening these out and creating a new mental construct to deal with the resultant smear.

That is why human languages are so imprecise. That's also why we end up talking and writing at length when we have nothing to say; and then get other people to agree.

Its the old problem of "I know you think you understand you heard but I don't think you realize that what I said was not what I meant."

Precise communication, or more precisely sloppy but comprehensible communication, is scarcely possible with things like an insufficient alphabet, like Hebrew which was/is written without any vowels, or diacritical marks, like English which is written one way and pronounced any which way.

The real reason the Jewish world places such importance on rabbinical studies is that the transmission of historical texts is part of an oral process required by their lousy vowel-less alphabet. I'm sure I could find other examples. I'm staying far, far away from ideogramatic languages like Chinese, Japanese, Korean and others.

The lack of diacritical marks leads to wars and jokes. The joke amongst translators and interpretors in that "In French, you can know how to speak and write any word without ever knowing what it means, while in English, you can know the meaning of a word without having a clue how to speak or write it."

I suspect that the (dis)ability to construct an alphabet without properly diacritically marked vowels is the same (dis)ability that afficts anyone looking at a photomicrograph of a VLSI chip.

The people are all looking for the transistors and shit while the real wonder, the traces, the incredible wealth of the traces, is glossed over as "Well, that's just a trace."

Ahem! The original inventors of the transistors, Robert Noyce, who was at Fairchild Semiconductor and Jack Kilby, who was at Texas Instruments, got rich and famous, not because of their work with components, but because they found a solution to the inter-connection problem.

(Image copyright Jean Hoerni and Robert Noyce.)

In fact, the component doesn't matter, nor does the composition of the component; it doesn't matter if you're looking at a germanium transistor or a silicon resistor. I seriously doubt that anyone reading this, or listening on the podcast, could tell the difference.

What is common, invariant and yet overwhelmingly flexible is the trace from one component to another, or to nothing. People have been ignoring the very thing that has made the biggest impact on modern civilization.

OiRc-0008 A question of semantics

As I am reviewing my class notes for my system's class, I am struck by the realization of the thought pattern underlying the difference between the common view and my view of just about everything but of OiRcs in particular.

It begins deep in the use of English. Being bilingual has its uses after all.

In English there is no easy way to describe relationships and there are no words to describe them. Thus A<->B becomes two sentences:

• A relates to B, and

• B is related to A.

The very words used to describe the relationships are terms like 'has,' 'owns' and 'is a member of,' 'belongs to' and so on. There is no terms in there for 'under what circumstance' and no description of cardinality, mutability and optionality.

And therein lies the problem.

Apart from the awkward switch in tenses depending on the direction one is looking (A to B or B to A) and the generally undescriptive term used to describe the relationship, the relationship is not described first. Instead it is a verb sandwiched between two mouns and it needs to change tense depending on how one is looking at it.

This is wrong. Just plain wrong.

I propose that the relationship be instead described by a noun, not a verb.
Thus A 'owns' B becomes 'has a' relates one A and many B.

Since 'has a' is not an appropriate lin guistic term, it needs to be replaced by some meaning forl word, usually this will be a noun.

Thus Library has Members becomes Membership relates One Library and Many Entities. (I am skipping a head of myself a bit since Entities could be described as People, and Library is a Role that an instance of Entities is playing.

Playing is itself a relationship between a Role and an Entities. This means that the same entity can a lender and a borrower be. (With apologies to Hamlet, or at least to Shakespeare.)

This brings about an interesting condition: Recursion.

Thus Membership relates One Library, which is a Role an Entity can Play, and Many Entities. Relationships can recursively relate other relationships to each other or to object instances.

OiRc-0007 Properly untangling the Gordian knot

Regardless of however many levels of Relationships lie between the Objects, you still need a way to array all of them in an orderly fashion.

Topological sorting of all of the objects is the only way to accomplish this, sorting objects topologically close to their owners. (You would probably want to add methods to disambiguate or perhaps sort the objects.)

In Smalltalk this is probably best described by:

 topologicalSort: aDAGInADictionary
  "input aDAGInADictionary -> a Dictionary of all the nodes in the system
   it associates a node label with a collection of its dependent nodes"
 | virgins nodesInReverseOrder visitBlock |
  virgins := aDAGInADictionary keys.
  nodesInReverseOrder := OrderedCollection new. "unless you're sorting 'em"
  visitBlock := [:aNode   |
      virgins remove: aNode.  "another one bites the dust"
     (aDAGInADictionary at: aNode) do: [:anArray  |
          anArray do: [:anotherNode  |
             (virgins includes: anotherNode)
                  ifTrue: [visitBlock value: aNode]]].
      "add me after all of my successors and their successors, etc.
      have been added"
      nodesInReverseOrder add: aNode
     ].
   aDAGInADictionary keys do: [:aNode |
      (virgins includes: aNode)
          ifTrue: [visitBlock value: aNode ]].
^nodesInReverseOrder reverse "but not if they're being sorted"

Simple and elegant, no?

Of course how you define the Dictionary which is the parameter to the method is everything.

It must consist of entries associating each the Objects to which each node entry to which it is related.

Since I hadn't fully evolved the concept of Relationships back when I was writing this, it is incomplete and in I would be in need of a patron to keep me alive while I untangle the web we weave, when first we practise to reveal.


Suffice it to say that each Relationship from one Object to another should be represented as a fully formed line instance, arrayed between each object.

I have given some thought about how these should be drawn and I will reveal it in a few days, after I get out of school and have more time to devote to the answer.

OiRc-0006 Cutting through the thicket

If you're paying any attention, you've noticed that I used to be far more timid in my promotion of Relationships.

The example code in the previous entry has Relationships but it doesn't have nearly enough.

I still had the concept of radixes into 'code tables' as

• radixTable( aTableSymbolString, aLanguageRadix) answer any radixed value sets (array of labels) to associate aTableSymbolString, aRadix with a string value. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where sets named aTableSymbolName are stored in the table as aTableSymbolName, languageRadix, setRadix => aString.metadata
• slotLabel( aLanguageRadix, slotName) answers a label for a slot named aSlotNamed in language aLanguageRadix. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where slot named className, slotName, languageRadix => aString.metadata

This was an error that I can only attribute to the depth of a habit of embedding references to other objects in other objects.

Its one thing to being able to draw a distinction between business object data models and another one to fully realize that system design should be made up of 'a few rules, ruthlesly applied' (I think thanks or apologies are due to Alan Kay, the founder of Smalltalk, for that quote but I've just Googled it and I seem to be quoting myself again.)

The habit was hard to break. It took me years so I don't expect to encounter it in the wild for a while yet.

Part of my problem was that I knew that dis-embedding the references to radixes would lead to much a more complex schema definition.

It would be harder to visualize, harder to manipulate and harder to implement systems based on this vision, some might call it a near hallucination, of Objects and Relationships.

I will revisit my notes from my exploration of the complex and wonderfully normalized database schema that revealed 750+ Objects and 1,200+ Relationships. But if, as I suspect, it also made the distinction between Business Objects and radixes into code tables, the 750+ objects was infact an underestimation.

More in the next blog entry.

OiRc-0005 A question of scale

Why did I ever do database visualization in 3D with VRML?

I had been working with a large, complex database, never mind where or should for whom, and I wanted to see it.

It defined or was defined by 750 objects. That's seven hundred and fifty object, and countless instances but I don't have to care about them.

Now how do you show 750 objects? Being an architecture student, which if you've been following along you already know and you can guess where I'm going with this, I am familiar with 3D.

The rationale for using VR and three dimensions is the following:

• On a static linear presentation, we can present, illegibly, a dozen objects in a row. (12)
• Extending this in two dimensions, we can present, illegibly, one hundred and forty-four object on a plane. (144)
• Extending this to three dimensions and using a VR browser, we can present one thousand, seven hundred and twenty-eight objects in a cube. (1,728).

Now, that's a lot more than the 750 objects I was faced with when trying to visualize the dataverse. Keep in mind that the 750 objects are local to a database and the Relationships revealed through an examination of the database for foreign keys are also local.

They don't have to be, which gets me back to the theme explored in OiRc-0001 Zip, nada, nothing, Sweet Fanny Adam. Ownership of specific memes is possible using the internet wisely.

I've already thought of this and out it in a wiki web page. Since I can't garantee that the page will survive all the turmoil in my house I'm including and comment on it:

A scheme for database presentation/interaction in VRML:

Disposition

a) Array the persistency mechanisms on the surface of a series of imaginary nested spheres. (0)

b) Topologically sort the persistency mechanisms (and therefore the objects mapped onto them) by the relationships in which they participate (1)(2) to provide the necessary information to position the persistency mechanisms and object classes in 3D.

c) Sometimes the mapping between tables (T) and objects (O) (T:O) will not be 1:1.

c1) The tables should be thought of as sections running from the surface to the center of a sphere. The objects should be distributed in the section as per their hierarchy. If database views are being used to 'simplify' access, objects representing the views can span several sections.

Tables and files, API'd legacy systems and other persistent external storage mechanisms should be rendered as colored 'tiles' on the surface of the nested imaginary sphere on which they are arrayed in sections. Differentiation between the types of persistency mechanisms can be accomplished by mapping a texture in addition to a color and providing a legend of any texture mapping used.

Objects are colored 'spheres' on or inside the 'tile' to which they are mapped. Relationships are thin 'rods' that run between tables and objects. They should probably be run in channels between the sections.

Color and opacity/transparency:

Color is best thought of as saturated CYMK (Cyan, Yellow, Magenta and Black) on a white or pale primary RGB (Red, Green or Blue,) colored background. The assignment of colors is arbitrary except that the mapping is the same as that used in creating real-world four color maps. The recently proved four color map theorem states that it will always be possible to construct a map where each object and each relationship will be dintinguished from adjacent objects and relationships with only the use of CMYK as color keys.

Opacity is an alpha channel quantity which should reflect the degree of interest in objects. Classifying objects as belonging to various systems and sub systems, it becomes possible to set the opacity to a low value for objects and relationships that are not relevant and high value for objects that are relevant. Nesting objects/tables should be partially saturated so that the reveal the nested objects/tables/relationships.

Given the computational burden imposed by the architectural presentation scheme, it should be generated only when the underlying data model changes.

The interaction and 3D manipulation, rotation and navitation can be provided by a VRML browser or an HTML browser VRML plug-in.

"Touching" a table, an object or a relationship should bring up any associated HTML description in a separate window or in a separate frame in a frame set.

Some interactive mechanism should be provided to allow the user to select a s(ubS)ystem and have the relevant objects, tables & relationships highlighted and irrelevant detail faded out. Execution of a macro adjusting the alpha channel is probably the simplest way to achieve this.

That leads us to the following data structures:

ALL objects have the following fields

ObjectUniqueID (128bits);

Mnemonic (128 bytes); (if none the UniqueID is used)

Description (String);

Class; (String, element of schema)

Version; (Integer)

Release; (Integer)

createUserDateTimeStamp;

activateUserDateTimeStamp;

alterUserDateTimeStamps; (OrderedCollection of UserDateTimeStamps)

inactivateUserDateTimeStamp;

dataDictionary (Dictionary of {Association of field=>value});

relationshipDictionary (Dictionary of relationship=>(OrderedCollection of ConnectionUniqueID)).

Connections consist of the following fields

ConnectionUniqueID (128bits);

Mnemonic (128 bytes); (if none the UniqueID is used)

Description (String);

Class; (String element of schema)

Version; (1)

Release; (0)

createUserDateTimeStamp;

connectUserDateTimeStamp;

alterUserDateTimeStamps; (OrderedCollection of UserDateTimeStamps)

disconnectUserDateTimeStamp;

dataDictionary (Dictionary of {Association of field=>value});

relationshipDictionary (Dictionary of relationship=>(OrderedCollection of ObjectUniqueID)).

This schema is the subject of another article.

RDObject

Associated_HTML_description;

it will be assigned

position (XYZ);

color (CYMK-alpha).

Participating in

RDObject<->RDMapping;

RDObject<->RDRelationship;

RDS(ub)ystem<->RDObject.

RDTable

Associated_HTML_description;

it will be assigned

position (XYZ);

color (CYMK-alpha).

Participating in

RDTable<->RDMapping;

RDTable<->RDRelationship;

RDS(ub)ystem<->RDTable.

RDMapping

Associated_HTML_description;

RDTable{,RDTable}:RDObject{,RDObject} {;RDTable{,RDTable}:RDObject{,RDObject}}.

Participating in

RDObject<->RDMapping

RDTable<->RDMapping.

RDRelationship

Associated_HTML_description;

RDObject|RDTable{,RDObject|RDTable}; 0|1|n:0|1|(N|M); RDObject|RDTable{[,RDObject|RDTable};

it will be assigned

startPosition (XYZ){,articulationPosition (XYZ)} {;startPosition (XYZ){,articulationPosition (XYZ)}}:

joinPosition (XYZ);

articulationPosition (XYZ){,articulationPosition (XYZ)};

joinPosition (XYZ);

{articulationPosition (XYZ),}endPosition (XYZ) {;{articulationPosition (XYZ),} endPosition (XYZ)}.

Participating in

RDObject<->RDRelationship;

RDTable<->RDRelationship;

RDS(ub)ystem<->RDRelationship.

RDS(ub)ystem

Associated_HTML_description;

RDObject{,RDObject};

RDRelationship{,RDRelationship};

RDTable{,RDTable};

RDS(ub)ystem{,RDS(ub)ystem}

Participating in

RDS(ub)ystem<->RDObject;

RDS(ub)ystem<->RDTable;

RDS(ub)ystem<->RDRelationship;

RDS(ub)ystem<->RDS(ub)ystems.

0) The rationale for using VR and three dimensions is the following:

• On a static linear presentation, we can present, illegibly, a dozen objects in a row. (12)
• Extending this in two dimensions, we can present, illegibly, one hundred and forty-four object on a plane. (144)
• Extending this to three dimensions and using a VR browser, we can present one thousand, seven hundred and twenty-eight objects in a cube. (1,728).

1) The relationships themselves are a special class of problem since there may be several functional/state-based relationships between two tables which will not necessarily be revealed since one table (T) will only have one foreign key (FK) to another table (T') which would satisfy the relational calculus but not the actual object model. It is therefore necessary to delve deeper into the object model than simply relying on the data model. It is a starting point but not

2) Tables which have no dependencies on other tables (which don't have foreign keys) are arrayed on the outermost sphere. The nesting depth of a table (T) depends on nesting of relationships to other tables (T'..T). It will be positioned one level deeper than the deepest in T'..T;.

The schema was well enough defined that I could find all foreign keys and link them to their specific tables

Kudos to ScreenCastsOnline

We're taking a break from the pontificating to report that I've had some success at posting my audio feed here at http://oirc.libsyn.com/ and publishing it to iTunes. LibSyn is pretty usable and pretty cheap.






That should take care of half of the equation.

Now I have to work on my production environment, which is currently in useless figurative rubble at the other end of my condo. So much money spent and I can't even get AirPort Extreme signals to transmit from one end of the place to the other. You can't beat plaster on lath over brick shell building construction but sometimes you wish you could. Wireless works through the floor and ceiling but not through the wall. Geez!

And I'm not too happy with other things either (Like, how do I clone this damn G4 powerbook hard drive so that I can move everything to my G5 iMac which as four times the RAM and three times the clock speed?)

The audios and videos are intended to complement, supplement, condense and clarify the textual material which can be found on this blog.

I still like using a wiki for a collaborative work space but I must admit the blog concept rocks for uneditable works. All you can do is comment on things.

This milestone is brought to you courtesy of the instructional vodcasts I found at Screen Casts Online and the great and useful information by Don McAllister that I found there. Go there and vote for them at PodCast Alley.

Yahoo!! I'm the OiRc Podcast on the iTunes Music Store. My test 'casts are working. :-)

Now that the preliminaries are over, I can get on with the rest of the work.

Although my SysAdmin friend just called and said I had someone hacking into my Linux box as root from the NETHERLANDS. Damn... Small world, ain't it?

OiRc-0004 The library system revisited

A few years later, in 2002, while I was recuperating from the effects of 9/11 and the devastation wrought on the buildings that were literally my next door neighbours, I had a chance to revisit the Library system and come up with a better definition for the object model.

I was still cogitating; mulling over the real impact of relationships on software design. Like a dutiful son, I was going back to the family business and mining it for the nuggets of insight in what was after all familiar ground.

I was beginning to come to grips with Relationships.

Once again, I return to my wiki.

An Object model

This is where every Class and the hierarchy of every Class is defined and every Relationships is defined.

Functionally the definitions are:

every instantiable class shall define class methods to:

• new() return a new empty intance of itself.
• fromXMLString( aString ) return a new instance of itself filled with aString
• fromDatabase( aDatabase, aTable, aKey ) return a new instance of itself filled with a row returned data obtained by query against aDataBase in aTable for aKey.
• radixTable( aTableSymbolString, aLanguageRadix) answer any radixed value sets (array of labels) to associate aTableSymbolString, aRadix with a string value. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where sets named aTableSymbolName are stored in the table as aTableSymbolName, languageRadix, setRadix => aString.metadata
• slotLabel( aLanguageRadix, slotName) answers a label for a slot named aSlotNamed in language aLanguageRadix. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where slot named className, slotName, languageRadix => aString.metadata

every instantiable class shall define instance methods to:

• get() its constituent slots
• get() its constituent slots
• set( aValue ) its constituent slots
• set(, aValue) its constituent slots
• asXMLString() return itself as an XML string
• asTable(aLanguageRadix) returns itself for interaction as a table with its rows with each slot defined as one datumLabelStyle, slotLabel(slotLabel, aLanguageRadix)datumValueStyle, value row per slot and

one col spanned subtable for any instantiableFragment.

• fromTable(aTable) fills its slots with the contents of aTable. The table is the same as would have been answered by asTable()
• asTableRows(aLanguageRadix) returns itself for display as a table rows.

one datumLabelStyle, slotLabel(slotLabel, aLanguageRadix)datumValueStyle, value row per slot. If the slot is a compound instantiableFagment, it will be asked to answer itself asTableRows(aLanguageRadix).

Structurally the definitions are:

InstantiableFragment

objects can be instantiated but have no independent existence. They are only have meaning when embedded within other object instances.

Superclass: Object Instance Variables are:

• NONE

The following classes are subclasses of InstantiableFragment:

Amount

objects define the monetary cost or value of an object

Superclass: Object Instance GVariables are:

• currencyID Integer(3) radix of an item in a CurrencyTable
• currency String(14) is the currencyID is nil
• date Date
• amount FixedDecimal(14) the quantity of specie involved.

RecordID

objects define how the entire system handles uniqueness identifiers.

Superclass: InstantiableFragment Instance Variables are:

• recordID Integer (14) AutoIncrement

DateTimeStamp

objects record the date and time of an event such as record creation, update, deletion, or state change.

Superclass: InstantiableFragment Instance Variables are:

• date Date (yyyymmdd)
• time Time (hhmmsstht)

Operator

objects record the ID of the agent that created, updated, deleted a record or caused a state change. The ID can be that of a human being or of a batch process. They are stored in a CRUDE table

Superclass: InstantiableFragment Instance Variables are:

• operatorID String(14)
• memberID RecordID the ID of any member human agent

Address

objects record the position in space of an object

Superclass: InstantiableFragment Instance Variables are:

• countryID Integer(3) radix of item in a CountryTable
• countryName String(64) name of the country if radix is nil
• postalID String(16) depending on the countryID this is variously called a ZIP Code, PostalCode, Code Postal or some other nmemonic.
• firstDivision String(64) depending on the countryID this is variously called a State, Province, Prefecture, Departement or some other geopolitical boundary
• secondDivision String(64) depending on the countryID this may be ommitted of refers to a county or other geopolitical boundary.
• city String(64) name of the city of residence
• streetName String(64) coarse grained postal service location marker
• streetNumber String(64) fine grained postal service location marker
• internalRoute String(64) internal routing post postal delivery mechanism
• homePhone String(32)
• workPhone String(32)
• homeFax String(32)
• workFax String(32)
• homeEMail String(64)
• workEMail String(64)

Name

objects record the human nmemonic identifier of an object

Superclass: InstantiableFragment Instance Variables are:

• salutationID Integer(2) radix of item in a SalutationTable

1=> Mr.

2=> Mrs.

3=> Ms.

4=> Lord ...

• salutation String(12) if salutationID is nil
• nameType Integer(1)

1=> corporation, Ln

2=> individual, FnMiLn

3=> individual, LnFnMi

4=> Amerind, Mi(Band Number),FnLn

• lastName String(64) patronimic or or corporation name
• firstName String(64) filionimic
• middleInitial String(16) (may be Band Number for Amerinds)
• suffixID Integer(2) radix of item in a SuffixTable

1=> Esq.

2=> 2nd.

3=> 3rd.

4=> 4th. ...

• suffix String(16) if suffixID is nil.

Abstract classes

ModelObject

objects are abstract (uninstantiable) objects that define structure and behavior for their subclasses. They define the relationship between objects and the table that stores them.

Superclass: Object Instance Variables are:

• uniqueID RecordID
• createDTS DateTimeStamp
• createOID OperatorID
• updateDTS DateTimeStamp
• updateOID OperatorID
• deleteDTS DateTimeStamp
• deleteOID OperatorID
• objectID String(14) name of the object Class for reinstantiation from persistent store
• tableName String(14) name of the table where a persistent copy of the object is/will be stored
• nmemonic String(255) human readable nmemonic device.
• description String(1024) human readable description of the object

Concrete classes

Location

object is a point in space time where an Entity can be found.

Superclass: ModelObject Instance Variables are:

• locationID RecordID
• address Address
• effectiveFrom Date nil implies since record creation

when the date is partial, this implies a cyclic relocation

• effectiveUntil Date nil implies forever

Entity

object is a person or corporation

Superclass: ModelObject Instance Variables are:

• name Name
• roleID Integer(2) radix of item in a RoleTable

1=> Library

2=> Member

3=> Supplier

4=> Publisher

5=> Operator

• role String(12) if roleID is nil

Library

object is the library itself

Superclass: ModelObject Instance Variables are:

• entityID RecordID
• sic String(16) Standard Industry Code
• tin String(16) Tax ID Number

Acquisition

object is any item acquired for the purposes of presentation or circulation

Superclass: ModelObject Instance Variables are:

the uniquenessID is known as an accession number

• content String(1024) This may be a CSV string which can be parsed further
• costOfPurchase Amount the price paid to acquire the object
• costOfReplacement Amount the price which would be paid to replace the objec
• Circulatable Boolean

True=> this acquisition can leave the library premises

False=> For viewing in reference section only

Member

object can play service recipient roles in circulation

Superclass: ModelObject Instance Variables are:

the uniquenessID is known as a membership number

• entityID RecordID
• since Date
• renewalDue Date
• outstandingFines Amount

Catalogue

object describe any identical accessions

Superclass: ModelObject Instance Variables are:

the uniquenessID is known as a card image number for historical reasons

• cardImage String(2028) contains the catalog card/entry image
• typeID Integer(2) radix into a TypeTable

1=> Book

2=> Periodical

3=> Manuscript

4=> Audio Tape

5=> Audio CD

6=> URL

• type String(12) is typeID is nil
• externalID String(16) ISBN, ISSN, UPC or other real world designation
• publicationLocation Address
• publicationDate Date
• metric Integer(5) # of pages, running time or other indication of heft
• dimensions String(64) physical/spacial dimensions, if applicable
• summary String(64) may de redundant?
• accompanyingMaterialID Integer(2) radix into a MaterialTable

1=> ?

• accompanyingMaterial String(12) is accompanyingMaterialID is nil

Category

object describes the search taxonomy

Superclass: ModelObject Instance Variables are:

• superCategory RecordID (optimization feature only)

the mnemonic is the category name

subcategories are dynamically constructed and cached in a single structure

Keyword

object provides indexes into the search space

Superclass: ModelObject Instance Variables are:

the mnemonic is the keyword

index

object provides links between keywords and the search taxonomy

Superclass: ModelObject Instance Variables are:

• taxonomyID RecordID of the category
• keywordID RecordID of the keyword

Relationships

These define the articulations of the library system and provide for its functionality.

In case you're wondering these are index tables. In many database systems they would be defined as external keys and stored with the objects (a Fourth Normal Form no no but a good idea for quick relationship reconstruction after crashes.)

For our purposes, we will define one table per relationship and store connections in rows consisting of the owner objectID, row RecordID, member objectID, row RecordID.

This system had been remarkable for being defined without any participation sort order and this perhaps might need to be addressed. The sort information (one or more member slot name and collating sequence,) is defined in the relationship and the specific values are stored in-fixed between the owner data and the member data in the connection row.

Relational integrity is maintained very simply by sweeping through the indexes looking for connection rows where an object might have been participating in a relationship and deleting the connections. If recessary, the object referred to would also be deleted (recursively calling the delete routine,) before executing the actual deletion of the connection.

All relationships are subclasses of the generic Relationship class and all connections are instances of the generic Connection class.

The methods of the Connection class are markably simple.

Connection

object provides links between persistent object instances

Superclass: Object Instance Variables are:

• connectionID RecordID
• relationshipID Integer radix identifying the connection class
• ownerID RecordID
• orderString String
• member ID RecordID

class method:

• connect: anObject to: anotherObject via: aRelationship

instance method:

• disconnect via aRelationship

EntityN-m-:isWhere:M--Location

define the, possibly periodic, position in space/time of any entity or group of entities such as a family. It should be deleted when deleting the last entity at that location.

Library1-m-:is:1-d-Entity

defines the library entity, its deleted with the library (entity should be a library.)

Member1-m-:is:1-d-Entity

defines the member entity, its deleted with the member (entity should be a member.)

• birthDate Date
• adhesionDate Date

---

• schoolGrade
• schoolTeacher

Library1-m-:holding:0N--Acquisition

defines a library's holdings

Member1-m-:familyGroup:0N--Member

defines family groups of members

Member0N-m:reservation:0M--Catalogue

defines the reservation of (m)any catalogue item. The limit on the number of links from any member (max reservations by a member) or from any catalogue item (max reservation before we stop trying to enforce them) is a matter of policy.

Member01-m-:onLoan:0N--Acquisition

defines the loan of acquisitions to members. The entire system is being evolved to maintain this information. Strangely enough its not even worth its own independent object. Its a valued connection node. The limit on the number of link from any member (max loans) is a matter of policy. Just to keep things interesting and on the cutting edge (see AdvancedRelationshipTheory), these connections carry data:

• loanDate Date on which the acquisition was circulated.
• dueDate Date by which the acquisition is supposed to be returned.
• returnDate Date on which the acquisition was returned.
• loanState radix into LoanStateMachine.

Acquisition1--:supplier:N--Entity

defines the supplier of the acquisition (entity should be a supplier.)

Acquisition1--:author:N--Entity

defines the author of the acquisition (entity should be an author.)

Catalog0N--:publisher:1-m-Entity

defines the publisher of the catalog item (entity should be a publisher.)

Catalog0N-m-:classification:0N--Acquisition

defines the classication of a holding. There can be many copies of the same item

Category01-m-:taxonomy:0N--Category

defines the hierarchy of categories. (virtual relationship as the actual taxonomy is re-aggragated into dynamically constructed and cached single structure)

Category1-m-:catPivot:0N-d-index

defines the category-keyword search space

Keyword1-m-:keyPivot:0N-d-index

defines the keyword-category search space

Something I have to date neglected in the definition and use of state machines to describe

• Entity: birthday ->

juvenile |

adult.

• Acquisition: physical; state ->

ordered not yet received |

received not yet catalogued |

catalogued not yet on shelf |

onshelf reference only |

onshelf circulatable (no OnLoan connection exists) |

onshelf on loan (OnLoan connection exists) |

being repaired (RepairEntity connection exists) * I'll have to add this

widthdrawn

• OnLoan

on time (returnDate is nil & dueDate <= currentDate) |

late (returnDate is nil & dueDate > currentDate) |

lost (returnDate NOT nil & loanState is LOST)

You get the idea.

But sadly, I was making a mistake. Many of the data values are being carried as radixes into 'code tables'. This is infact an N:1 relationship. While the class defines many instances, only one of them participates in a relationship with (and therefore has a connection to) the object instance. (I know. Its hard to keep all these relationships and conections straight.)

Likewise, OnLoan is a state machine and the value is actually a relationship that an instance has with the OnLoan state machine.

We'll get to how I was able to discover the origin of the error and what I did to solve a completely different problem which led me to a few epiphanies; specifically about visualization of a large and complex database.

OiRc-0003 Early designs for a library system

LibrarySystem

As the son of a professional librarian, Anna Rovira, the librarian who set up the first computerized library system in Quebec, Canada, I had the opportunity to be exposed to a great deal of information (and the occasional ''juicy'' epithet hurled at MIS folks, [Think librarians are ''quiet little ol' ladies?'' Think again. They know all the ''dirty words'' and a lot more that you've never even heard of. They are second only to mathematicians in their alcohol consumption capacity and as ribald a bunch as have reddened my ears.] :-) about the data structures and functionality of a public library.

In fact it shaped my understanding of my profession before I even knew it was going to be my profession. I started my school life as an engineer and an architect by inclination. I thought in terms of Frank Lloyd Wright, Ludwig Mies van der Rohe and Buckminster Fuller and I wasn't aware of the existence of Donald Knuth or John McCarthy or Alan Kay.

Rather than plow old ground that I honestly haven't seen in years, its been done by others much better than I could do it. I will instead point to a great source of information and defer to Library Information Interchange Standards and here is a good glossary and another and another.

As we evolve the data structure to support the functionality a library system must have and extend to what functionality it could possibly have if we exploit the data structures and object relationships to their fullest, it will become clear that there's a lot more to systems design than ''Use Cases''.

Data Structure

Lets start with the two basic objects:

a Library and
a Member.

Leaving aside for the moment the possibility of inter-library loans, we are going to explore the objects and their relationships. We will describe the syntax of our discussion more fully in RelationshipNomenclatureAndSymbology. Suffice it to say that the diagrams are slightly modified BachmanDiagrams for rendering as text-only in a fixed width font.

For the scope of this system, we will consider a single library system. A single entity which lends material to its membership. Exploring this yields the folowing structure:

. Library --> Member

What constitutes this relationship? The library lend material to its members. This material can be books, periodials, audio/visual resources. The library tracks all of its material as acquisition and the purchases by accession numbers. This yelds the folowing data structure diagram:

Grrr! There is one reason to hate the editor that you get with blogger. I can't draw the ascii art that appear on my original wiki page. It loses the interword spacing and collapses it all back to a single space. I'll have to speak to somebody about this.

. .-----------------------------.
. | v
. Library --> Acquisition |<--| Member

This is the basis for a Circulation system.

First though, lets take a moment to notice something about both these objects. They are both entities and any Entity has a Location in space/time. Of course a location can be shared by many entities. And Entities can change their Location over time (perhaps periodically).

. Location
. ^
. |
. v
. .----------- Entity ----------.
. |.---------------------------.|
. || v|
. Library --> Acquisition |<--| Member


Now the relationship between a Library's Members and a Library's Acquisitions is not as simple as the ownership relationship between the Library and its Acquisitions. Members can borrow individual Acquisitions or they can reserve any copy of a similar Acquisition.

This gets us into the basic functionality of circulation. We'll get back to function in a moment. While we circulate an Acquisition we reserve any acquisitions which is described in a Catalogue. We are now going to explore cataloguing.

Location
^
|
v
.----------- Entity ----------.
|.---------------------------.|
|| v|
Library --> Acquisition |<--| Member
^ ^
| |
Catalogue <--------.

Now in order to be useful, a catalogue has to be organized (you'll see why just being searchable isn't enough in a second,) and the mechanism used since the founding of the Great Library of Alexandria is the use of a taxonomy (which for the sale of simplicity we'll call a Category).

If you use only keywords, you can't even formulate a proper query. Think about this: ''Is a word used in an Acquisition or in a query an author, a subject, a title or something else altogether?'' Shakespeare was the author of many plays, the subject of a lot of books by other people and has been the title of many books and movies.

Location
^
|
v
.----------- Entity ----------.
|.---------------------------.|
|| v|
Library --> Acquisition |<--| Member
^ ^
| |
Catalogue <--------.
^
|
v
.-> Category->index
| | ^
'-----' |
Keyword

These are the basic objects apart from a few additional relationships between:

• Catalogue antry and the entity known as its publisher,
• the Entity know as its authority and between an
• Acquisition the entity known as its vendor and
• Member and another (family) member .

Location
^.--------------------.
||.------------------.|
v|| |A
.----------- Entity ----------. |
|.---------------------------.|.--. |
|| v|v | |
Library --> Acquisition |<--| Member| |
^ \ ^ '-' |
| '-A | |
Catalogue <--------. |
^ \ |
| '-----------------'
v
.-> Category->index
| | ^
'-----' |
Keyword

On-page connectors like A there are why I developped ArticleRoviraRepresentations a technique for seeing tables and relationships in 3D. (I can't pull it up and it deserves its own entry so you'll just have to wait. :-)

Functional Structure

So what can we do with this data structure? (Here we touch CRUDE matrices and the ConceptsOfApplicationSecurity, which is the subject of another wiki page I can't pull up right now and therefore another blog entry. :-)

• We can maintain the Library's information (and its related Entity and its related current Location.)
• We can Maintain any Member's information (and its related Entity and its related current Location.)
• We can maintain any Entity's information (and its related locations).
• We can maintain any Entity's Location information.
• We can maintain an Acquisition's information (and its related Supplier Entity and its related Catalog entry.)
• We can maintain Keyword entries.
• We can maintain any Category and its relationships to other categories and its relationships to Catalog entries.)
• We can maintain any Catalog entry's information (and its relationships to Acquisitions and its relationship to category/keyword entries.)

To make life simpler, we want a Front Desk to organize the functionality and to sweep through the database and to maintain things like:

• Membership maintenance (and produce Late Notices.)
• Reservations (Member Catalog relationship) (and produce Reservation Notices.)
• Loans (creating a Member Acquisition relationship)
• Returns (Dissolving a Member Acquisition relationship)

To make life simpler, we want a Cataloging Desk to organize the functionality of the catalog and the indexing of acquisitions and maintain things like:

• Suppliers
• Categories (and category taxonomy.)
• Keywords
• Catalogue entries

I have mercifully omitted See and See Also references but these are actually just N:M relationships between catalogue entries. (Actually I've got some thoughts about objects and relationships that have to be seen to really be Groked' :-)

To make life simpler, we want an Acquisition Desk to organize fhe functionality and to maintain things like:

• Supplier Entries,
• The links to Catalogue entries (and produce New Acquisitions Notices.)

So far, this stuff is all back-end or ''behind the desk'' functionality.

For the membership, we want Reference Desk functionality which will allow them to explore the entire holding regardless complexity and play with keyword searches and the taxonomy. (For this we might want to allow this to spawn windows and to change search pivots from taxonomy to keyword.)

There are a couple of things missing from this analysis. Chief among there are:

• Objects instances have states
• relationships should be clearly named

We'll return to the topic in a future cast.

OiRc-0002 What a lo-ong strange trip its been. (Apologies to the Grateful Dead.)

Sometimes I wonder how I got to where I am in my profession.

I'm a manager in IT (Information Technology), formerly known as DP (Data Processing,) though it was known for a while in Canada by the sexier moniker of Informatics.

I can't help but thank my high school arthitecture teacher, Stan Klasa, who prompty disabused me of a career in architecture in Montreal Quebec Canada. Its no way to make a living. You'll never get rich and the decisions are all made else where. He meant Toronto, Ontario, Canada but he might as well have said Mars.

I sort of dropped architecture as a profession/vocation, bounced around becoming what Grace Slick called a person our parents warned us about went to CEGEP (Wikipedia provides a definition: Collège d'enseignement général et professionnel translates to College of General and Vocational Education which sort of what junior college is in the 'States) and had a job selling screws (industrial fasteners.)

I bumped into a friend of mine, Andrew Morrow, who I'd met in the math lab at Dawson College, the aforementionned CEGEP, and he had a job going where he worked.

I just realized that this is a topic that I do not want to go into into too much detail because I realized that I refered to most of my collegues in less that glowing terms: Most programmers should be selling shoes.

Later, after years of handling other peoples orphan problems, those for which there was no easy solution, I came back to a simple problem: How do you model a wall?

Think about it... Its an everyday object, a wall. I've written about it on my wiki and one article says it best. (Unfortunately, I can't garantee that the page is always available so I'm sort of adapting it here. Quoting one's self is something that should be avoided but nobody's persuing the subject.)

The metaphorical wall

What is the difference between:

* a pile of bricks and a sack of mortar at Home Depot,
* a garden wall keeping the flower bed out of the lawn and
* the cuppola of the Piazza Duomo in Florence.

If you've only leaned about objects in computer science classes, you probably can't even comprehend the unstated question never mind its answer.

None of your schooling has prepared you to perceive the question and all your schooling has conspired against ''grocking'' the answer.

In object-oriented thinking there is no difference.

All three are composed of bricks and mortar. The first is raw material at the store. The next is a mundane partition. The last is a masterpiece of Italian Renaissance architecture.

This brings us to an observation:

In object-oriented thinking, contained objects never know about their containers unless provided an explicit reference.

This existential clap-trap is saying that a brick can't know its part of a wall until you alter the definition of a brick to include a pointer to the wall that its in.

As broken fingernails on the hands of masons, demolition workers and prisoners everywehere can attest, bricks that are in a wall definitely don't need to be explicitely told they're in a wall.

In object-oriented thinking, you can't have different types of walls (indeed, you can't even have one realistic wall.)

So what's missing?

Relationships

None of the implementations of object-oriented systems, languages, modeling techniques etcetera (and few of the researchers [[and even fewer of the people currently messing up in IT shops around the globe,]) have any mechanisms capable of representing or dealing with relationships.

As we have (should) have learned since the mid-nineteen-eighties with the introduction of DB2, relational databases and the attempts at creating a relational calculus, (before the profitability of database companies and other vendors put the kibosh on research and education,) relationships come in very, very few flavors:

• 1:1 - one to one
• 1:N - one to many
• N:1 - many to one
• N:M - many to many

That's it. There are no more possible cases.

There are modifiers of course:

{0}|1{_}|{N} <-> {M}|1{_}|{0}

Meaning:

• can you possibly have no partipants and
• is having only one participant existentially different from having none or many participants and
• can you possibly have many participants in one side or the other of the relationship?

The mechanisms and complications immediately obscure that while basic and fundamental, trying to understand object architecture without relationships is akin to trying to understand physics without forces.

As LeCorbusier said: ''Architecture is about space.''

That was an elliptical way of saying that the relationships, however banal, are more important than the material being related.

And indeed our word for wall and the concept it embodies doesn't care about the composition of the wall or its function. A wall is an arrangement of objects in such a way as to exhibit certain relationships beteen themselves. It is entirely self-referential and scaleless.

Think of relationships as static (cached) or dynamic (query result) embodiments of the raisons d'etre for the objects in the first place.

I don't want to belabor the point or stretch the analogy but the moment you start seeing the relationships you start seeing their pervasiveness.

We will return to this theme and how it influenced my view of objects, instances, relationships and connections in the later blog entries.

OiRc 0001 Zip nada nothing Sweet Fanny Adam

This is voice-only podcast, and yes I could do video but there's no point in discussing something like ownership in anything than voice.

I've somethings to say but nothing to show. Hence, I get to go easy on my bandwidth with this podcast. That will change when we get into GUI designs and concepts that are more easily shown than talked about.

I'm also asking for feedback on this topic at OiRc@artdogs.org so you can reply, or expand on a point, suggest things or just call me an air head.

The topic this term in school, Metropolitan College of New York, Term 6, Fall of 2005, is Managing Financial Resources. So this first podcast is actually going to discuss managing financial resources.

In order to link it back to my obsession, object oriented software design and development, we're going to cover the economic aspects of object ownership.

Who really owns objects? What difference does it make? What are the benefits and costs of really using the internet to manage objects and instances?

Who really owns objects? This is actually trickier than it sounds, as is the assignment of responsibility for the objects, their instantiation, maintenance and dis-instantiation.

Lets take a case in point, the lowly ZIP code.

Its just a part of someone's address, right?

Well actually, its a relationship between a fixed location and a structure created by the United States Postal Service. In effect the USPS owns the ZIP codes. Zip actually stands for something: “Zoning Improvement Plan” and it was created to divide the geography according to the USPS distribution network.

The USPS are responsible for creating (instantiating) them, (then postmaster General John A. Gronouski announced that the ZIP Code would begin on July 1, 1963. About ten years later, Canada implemented its own postal coding system,)

They are responsible for maintaining them, adding, removing and altering codes when necessary for help them move the mail through changes in demographics. This can cause problems, like incorrect codes being used.

When the object definition of the zip code changes, like the USPS did back in 1983 to a 5 + 4 or 9 digit zip code, well that when it all falls down because, though the USPS owns the codes, they don't own the thousands of databases that their zip codes were used in.

That is a bigger problem than you think. Pay attention now, I'm actually on topic: Managing Financial Resources.

First there was an expensive advertising campaign, which didn't really reach the population. If you're a US citizen you're probably not using them even now and its been in use since 1983, since its now 2005,that shows you how much people are paying attention, and the problems of changing all of the data bases to reflect the desired reality is that it is entirely dependent on factors outside the control of the USPS.

Managing financial resources would lead me to question the wisdom of using advertising since there was such a low rate of return. Its like shoveling money into a high-efficiency furnace and hoping that people catch the small smoke signal. Are they looking? Are they interested? Chance favors the prepared mind. All the other ones don't mind and the message signal is lost in the noisy medium.

Every country has some variation of the zip code: the postal code in Canada, the postal code in England, to name a few I'm familiar with, and the geographic divisions of Prefecture in Japan, Departements in France and all the rest with which that I'm not familiar with. They all have the same problem.

Now there are ways the USPS could deal with the situation, such as just refusing to deliver mail, or sending it into a grey-hole for coding, the mail's eventual emergence being a mater of conjecture and occasional humor. People do start to get the message after a while. They update the definition of the databases, even if these are kept on the back of envelopes.

But it sets up the USPS for a repeat of the whole mess when, not if but when, they respond to changing conditions once again. Now once a piece of mail is sent, its sent. Its actual destination, coding and all, becomes a matter of historical record.

The problem lies not in the object instances, the actual pieces of mail, but in the object itself.

Enter the internet and IPv6.

128 bit's worth of pointers to objects. That works out to 340 onzetillion , 282 zentillion, 366 neptillion, 920 octillion, 938 septrillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607 trillion, 431 billion, 768 million, 211 thousand, 456 objects. That's a lot of objects. Don't worry about what the number groupings are called. I didn't and just made up the names. The point still remains. That's a lot of objects.

What if the corporate users of the USPS could just point to the entry in USPS database and not have to worry about how the USPS organizes the service.

Do we really care about how the codes are set up? Delivering the mail is the USPS's job, not ours. Do we really care about the hoops the USPS has to jump through to get the mail delivered? Do we care about how the USPS is organized?

How about UPS and FedEx who also use zip codes but use entirely different systems for routing based on their own delivery mechanisms.

Problem is that the zip code is used as a pretty tightly mapped geo-spacial coordinate system and used not just by the USPS but by anybody who needs to know where something specific lies. But the problem of multiple use merely exacerbates the problem of maintaining Zip codes.

Users, specially corporations, could supply the USPS, UPS, FedEx and other with a GPS code and let the carrier route however they need to in order to insure delivery within their specific Service Level Agreement parameters.

Thankfully, there's no truth to a proposal for vanity Zip codes. But, practically speaking, IPv6 could accommodate one since there is a disconnect between the real world and the cyber one. A DNS (domain name server) could accomplish that. Your email address or personal web page could contain a link to a GPS coordinate to where you happen to be, or where you happen to say you hang your hat.

Dang, that's not quite the direction that I wanted to go in. I'm solving the wrong problem.

Lets get back to the focus of this semester: Managing Financial Resources

How much does it cost to effectuate a change in the postal codes? Its a valid point as the costs from the last change in ZIP codes are still being assumed by agencies outside the USPS.

These agents are doing the changes but as inexpensively as possible as part of their scheduled or unscheduled maintenance cycles. But its still an enormously expensive undertaking, we're just spreading the cost over time (which gets into the time value of money,) and inconveniencing the USPS in the process as they can't just flip a switch on the external interface just like they do on their internal systems.

I think that this is enough for the first podcast. I've already wasted enough of your time. Or maybe not...

For feedback on this or any other topic email me at OiRc@artdogs.org You can reply, or expand on a point, suggest things or just call me an air head.

OiRc 0000.9 Intro into the pod/vodcasts

OiRc 0000.9

My name is Charles-A. Rovira and I'll be your host through this series of audio and video essays, though this feature is not strictly speaking an essay. Thesis, synthesis and conclusion are attempted here, but not strictly adhered to.

Since I am still learning this I am still not able to get podcast to you. This line of text will be replaced by the appropriate XML to RSS a pod/vod-cast to your machines as soon as I figure out how.

On this cast we're going to cover:

• What is a vodcast?

Its a video that is narrow cast to an iPod or to any computer that can download the files and play them. It relies on the internet to transfer content that you want, when you want. It also relies on sites, such as this one, to aggregate the information about the vodcasts so that it can be googled by those interested without you being inconvenienced by irrelevancies.

• Why vodcasting?

That's actually a fair question. In my case its because I have things to show people so it needs the video. Some episodes, like this one, won't need more than an honest face and a smile. Some episodes will need to highlight some techniques in topology.

I'd like to cover some technical matters like

1. cost, ($500 to $5,000 to $xxxx)
2. equipment – the equipment is starting from the barest bones, an iMac, an iSight web cam, and a host where I am putting up the content to an audio and video rig and some special effects software like a green screen, so I can merge virtual backgrounds (saving me the expense of building some real ones,)
3. software - most of it is free or extremely affordable, it lets me record, resequence, segment, tag upload, prepare and deliver my content to my website and to the aggregator.
4. time – it does take some time, some research, some training.
5. skill - I have none, so that's no longer a barrier to entry.

• What does this mean to my courses at MCNY?

It is after all an opportunity for me to advance my education as much as anything else.

We could look at Media studies; I'm a Canadian and a creature of the age of MacLuhan after all. I wonder what he would have made of the internet and its influence on media.

It breaks the synchronous nature of broad casting, where the broadcasters are selling access to 1,440 minutes in the day over a very limited number of channels and the audience, me and thee, is not in control of anything. It supplants it with near total control over the content you download and the content you upload.

The uploading of content means that you, the audience, is a participant in the media. You can contribute something. You are not prevented from having your say because of the traditional high barier to entry.

Here is a new point of view that is:

• anti-Leibnitz or at least Leibnitz's intent. An Apple computer ad said it best back in 1985 when they were creating desk top publishing: The power of the press belongs to those who own one. The concept was that now anybody could own one; even you, the lowly computer user, who had about five or ten or fifteen thousand bucks to spend on Apple equipment. The economics of publishing were such that even those atrocious sums gave rise to desktop publishing as a viable concept. Since my father was a printer, I can attest to the truth of the economics.
• anti-corporate. ClearChannel, Infinity Broadcasting, News Corporation & the other remaining members of the shrinking media cabal don't control this phenomenon; it is in fact a response to the abuses by the corporatists that are taking over more and more of our media and taking more and more time from any remaining content,
• democratic. As people take control of the content, instead of merely being subjected to whatever is approved for consumption, the number of voices out there (out here?) is growing.
  

Podcasts are, or can be, indexable, searchable and they can persist, just as books did, do and will continue to. We're not going to be rid of the broadcasters but we will be able to make our voices hear and our vision seen.

I am also pleased that content is available without advertising, or at least it can be, since the producers can recoup their costs without having to pay ungodly amounts for media distribution.

The cost component is becoming a bigger and bigger piece of the production of the content, because the content is delivered asynchronously, so you don't have to sit there while the clock is ticking, on the 1,440 minutes per day.

This frees the content provider from the tyranny of the clock because a one hour program could become a one hour and twenty minute program. You can make the format fit the content instead of trying to flesh out or shoehorn the content into a time slot.

That makes a consirable diference to the concept of what content is, what it can be, who pays for it, how it is paid for, how it is found, distributed, sought and delivered. (And I'd rather pay for content and get just content.)

That shift will put the traditional distribution network under severe stress since they have made their fortunes by selling something they have no real control over, your time, by controlling everything and anything you could watch and/or hear.

What is liberating content is the influence of the internet when combined with the empowering influence of the personal computer to producecontent.

We will explore one aspect of this with respect to my own obsession: the objects, instances, relationships and connections of the title and which make up the elements of my model of the world.

Lets take the focus of this semester: Managing Financial Resources which is the subject of my next piece.

What is OiRc about?

OiRc is primarily about two things:

1) Getting my MCNY bachelor's degree in business.

I'll be doing this by using this blog, a soon to be produced podcast to hold the text of my CA (Constructive Action) for this term: Managing Financial Resources and the eventual VodCast (Video on demand) about what this cast is really about.

2) Getting the word out about Objects, instances, Relationships and connections out to a very specialized crowd, the IT people who put us where we are today.

3) Getting some musical content out here. See my other blog for what I intend to do.

This blog, podcast and the vodcasts are not about media (though blogging has some big implications for content, content delivery, control over the timeliness of the delivery and over affiliations which were established by the broadcast model, the very model which sees itself as under attack by the internet and the time and location shifting that the internet enables.)

I am used to writing using a wiki, a collaborative workspace which is editable over time and where topics can be expanded on by giving them their own pages through the use of WikiWords which serve as anchors to the pages.

Instead I will have to change my writing style to adapt to the 'blog' scroll style of writing.

I am about to take several days to describe

• Abstract. (Which is actually written at the end, so it is definitly not easy to blog.)
• Topic Statement. (Which is sort of this entry, since this CA is a blog about blogging.)
• Situation Analysis. (Which describes the narrow view and the wider operational view in which I am writing this.)
• Workplace Analysis. (Where I describe the place(s) which are affected by the result of this work.)
• Needs Analysis. (Where I describe the lacunae of the workplace and/or the situation.)
• Opportunity Analysis. (Where I describe what the actual benefits of any action to be taken.)
• Plan Of Action. (Where I outline a potential course of action.)
• Background Research. (Where I give references for my sources. There are lots of them and some people as well who have helped my in my opus.)
• Annotated Bibliography. (Where I list all of my sources, though I am wondering if I should include stores and price lists.)
• Implementation Phase. (The fact that you're reading this indicates that it is being implemented and the blog 'scroll' style keeps the events and the sequence there of quite clear.)
• Final Assessment Phase. (Where will hopefully write that this was a success.)

This will be the structure of the blog but the podcast is about the structure of ownership and IP (Intellectual Property.)

Introduction

Well, here I go into the brave new world of blogging.

I will be linking to my audio and video blogs so stay tuned.

I am used to using a wiki so this is different for me.

This is my late cat wiki: