documents, schmocuments and Pluto (more about thingamy)

I really dislike the terms "documents", "forms" and "files". And "planets".

Sources of missed opportunities. Instigators of late evenings at the office. The mothers of all bounced mails. The source of unimportant academic discussions with no end.

Is Pluto a planet?

Who cares unless you must categorise, position it, tree-structure it? But as pigeonholing is the preferred way... then we have to care.

Even for "information", stuff you cannot sit on, we still end up using the same method. We cheat and imagine information as "documents" or "forms", finite stand-alone objects, which makes tree-structuring / categorising / pigeonholing possible.

Thus your address have to be copied onto your Health Records, your Insurance Contract, your other... eh... forms. Then those copies have to be maintained and updated with great care.

Thus last month's sales figures will be constructed from the accounts (more or less, depending on efficiency of the post office), from a sales report, from a spreadsheet somebody did the other day, from  yet another spreadsheet somebody else did another day and from...

Hello end-of-month reconciliation headaches, hello mailing lists when moving. Hello never being quite sure everything is right in a dynamic world.

Multiple "data" objects pretending to represent one single real world object? That never worked, and it will never work.

Consequently "forms" and "documents" should be a thing of the (paper-based) past. Full stop.

That's why we do not use tree-structures in thingamy. Nor do we use "forms" or "documents".

We chop stuff and information up into smallest possible objects so no real world object need to be represented by more than one single data-object; one single address object that is "related" to your bank accounts, your employment contract, to... you. And to your spouse, your children, your dog, the property developer, the insurance company, the...

Then we use more than one method, in combination or alone, to describe such relationships ensuring that we can use the objects in meaningful ways later in any way possible:

Object built from objects: Very precise, very inflexible. A bike-object is built of precise numbers of unique objects like a frame, wheels, a handlebar...
Thingamy can build classes (the cookie cutter to stamp out unique objects) using any type of property and/or other objects.

Tags (use of multiple tags, otherwise it would be categorising): Very generic, can be used for anything, could be all-encompassing but for one reason - it requires some discipline to get precise results in a hurry. Thingamy has a tag-browsing bar (see image) that can be used in any interface, report or even in the midst of a task.

Links: Quite generic and very precise, but sometimes too structured. Perfect for iffy objects like persons. In fact a person does not even have to be an object - just a cloud of linked objects; address, medication objects, bank accounts, children...
And the links are bidirectional: Choose an address object and you'll find everyone living there, who lived there, who built it, the insurer, you know. Link or unlink objects at any time.

Containers: OK, granted that tree structures cannot be fully avoided, like for physical position of stuff when you need to pick it up: Box 43, row 14, room B, Warehouse East is an obvious one.

Who said tinkering with software should be boring?

:)

Comments

[Mike O]

Sig, is "box 43, row 14, room B, Warehouse East" really a tree structure? or Is the widget just tagged with location attributes of "row = 14", "room = B", "box = 43","Warehouse = East", "latitude = 43.167354", "longitude = 5.608537", and "elevation = 2.1M". Is it a requirement for there to be a relationship between tags? It might be good to know that row 14 is in room B. If there is a relationship between these tags aren't there relationships and groupings of all tags? Should one be able to tag (group) tags and document relationships between tags? Wouldn't the relationship be valid only in the context of the specific widget (object)?

[sig]

Mike, interesting point, got me thinking this way: "Box 43, row 14 etc.." I would definitely define as treestructure as it indeed requires precise navigation, one right instead of left and your lost just like on the brancehs of a tree.

Now if the package was left in open space you would be the decisionmaker re. path to take to get there and Lat/Long would be better leaving more freedom to you the finder.

Common is still that physical objects can only reside in one place - while "information" should really not reside in a specific place. My problem with taxonomy (and documents, and forms) that, I would never find the Marmotte (Marmotta Marmotta) in that; it looks like a beaver and it lives in holes in the ground up in the Alps - but no way, beaver'ish it is not, it's a member of the squirrel family! Who would know unless you've been trained? Squirrels for me are little furry things jumping around in the trees, not what the Marmotte does at all :D

We do indeed use tags on tags (see the image? Upper box is for tags that's been used to tag other tags) - thus enabling relationships in groups.

Best is still to open for a combination: In thingamy you can use the tags and the historical browser and the links to narrow down in a report or choice: Say in an account report - what did Dr. Peter's patients cost us last Tuesday, limited to muscular pain related costs! Or what respiratory ilness medication was taken by all resident of this address over last three years! Could be useful, and of course only possible using unique objects that are linked, tagged and time-stamped :)