tags, not trees

Take my new tree-structure-free gizmo (pls use Firefox/Safari) out for a test drive:

What is it?

Whatever you want it to be: Navigation-free website. Tags-only blog. Complicated-to-simple database. Active resource picker. Knowledge and learning base. File system. Whatever. An experiment for the heck of it.

Basically a different approach to organise data, finding data, and transferring knowledge.

An example of no-tree-structure-at-all. Anataxonomy in practice:

• Organising:
  Free, dynamic and imprecise tagging of objects/subjects vs. fixed positioning in two-dimensional tree structure.
• Finding / Identity:
  Intersection/overlapping of multiple imprecise tags with no regard to sequence nor logic vs. precise navigation following learned standards / unique logical positions.
• Knowledge:
  Object/subject relationships directly visible in identity vs. identity plus large amounts of data linkage.

Enough talk, here's the tagwork, but first a few hints to ease you into it:

(Please, please use Firefox or Safari... anything but the "that browser which cannot be named", otherwise some features (modern technology and such) does not display nicely.)

1. Write "wa" in the field.
2. Click on "War", then "Wall" - see what happens.
3. Write "sm" in field instead.
4. Click "Smile".
5. Unclick "War".
6. Got it?
7. Click on any object-link and see whole text body, add comment (including more tags to comment) or add yet more tags to object/subject.
8. If you need to create a new tag use "Add tag" on top of tag list.
9. Please add another "art object" by hitting "Add object" on top of tag list and tag it at will!

[Note: The "art data base" is not the world's largest with its 15 objects (OK, I'm lazy, and no DB import function yet :), so feel free to add more objects. Anything is appreciated, it's only a test man!]

Now go there: http://thingamy.com/tagwork/ - enjoy! (pls use Firefox/Safari)

P.s.
The "tagwork" is a hands-on experiment, its traits are intrinsic to the Thingamy run-the-business system as base for the system's built-in communication (CMS, blog, mail-client etc.) and any interface where resources/data/objects/subjects have to be organised and found (HR, production, accounting, reports, etc), and choices have to be made (in process, workflow, etc.).

That said, the example have a nice admin back-end and can stand alone as a CMS, data repository, file system replacement (heh, why not?), blog system (let's add RSS and trackback), different take on wikis or whatever you could imagine.

Comments

[Ric]

That's starting to look like fun, Sig. Is this why your blog has been a little quiet?

The details are a little rough (e.g. having made an error, I would have liked to re-edit the comment - maybe I should stop making mistakes!) but eminently workable as a demo of the possibilities.

[sig]

The silence is a bit "summer induced" I'm afraid, the weather is so nice, long lunches and so forth ;)

Rough it is, and I thought I had to limit access to the admin interface for now... (except for some of course ;)

[Alex]

I like it a lot.

Hey Sig do I get any credit for the ...file system replacement (heh, why not?)... comment?

[sig]

Alex, of course, of course, I only forgot it ;) Herewith and hereforth, Alex' the man!

Will actually apply it as "file system" locally (non software firm where I have interests), dump the server file-structure, throw all files into the "database" and tag away... heh, can avoid all those samba issues too, delivery by apache instead! Cool, did not think of that...

Suspect that will end the amazing number of "I lost the file!"s :D

[Dennis Howlett]

nice idea...blog+wiki=collaborative software v2.0

[WAE]

You should definitely make a really simple archive navigator by auto tagging the date, month, and year as individual tags for any entry. A simplified archive navigator might be a separate tag browser for simply widdling down dates.

And if this was used for a blog, it would be better that the home page be unfiltered (unfiltered) include all tags with OR boolean argument. In fact, tag browsing should somehow allow ANDs and/or ORs. Maybe if you hold CTRL when picking a tag, it can be an OR select.

Other than that, this is way cool.

[frosty]

Hey Sig, I'm working on something a lot like this. Funny.

Quick comments from the trenches:

1) "ingress" is a little vague - and why is it needed in the first place?

2) if i've assigned three tags and want to unassign the first one, i have to kill the other two first. not good.

3) i assume clicking on a tag at the left should show me the tagged objects on the right, but that isn't happening (yes, i saved an object to test it). am i missing something, or is it broken?

Fun stuff, keep up the good work. When I have a prototype I'll be sure to ping you.

[frosty]

Oops, spoke too soon on #3.

I didn't realize you've AND-ed the tag selection.

I'd like to see that a little more obvious, and I'd like to see an easy way to OR them as well.

If I want "art OR action" right now I need to do each one separately I think, including *deselecting* one so I don't get "art AND action."

[sig]

Kevin, looking forward to see what you're up to!

Ingress is a bit much "publishy", I can see some missed that - but need a "field" that can be displayed separately during listing.

And of course the delete-tag-method is still imperfect - but this is a quick experiment so we did not bother :)

Ahh, and the boolean issue: AND + OR - well what shall I say...

In principle it's solved already as you pointed out; highlight whatever, then if it's not there de-highlight the one side of the OR and highlight the other and keep on playing.

I'm a bit suspicious that the boolean solution we're used to - in search fields for example is quite ingrained in our minds - and this method (which is of course AND/OR as well) gives the hiccups even if it opens for more playing and in-process creativity while still delivering...

I think I'll wait with a change to that until I have a bit more experience in how it works :)

[Dethe Elza]

You can make the realtime filtering *much* faster by keeping the tags in a list of lists: [[string,tag],[string,tag],...]. Caching them this way reduces your DOM traversal time astronomically. Once they are filtered, just use the cached tags to hide them.

[Dethe Elza]

Have you considered using Scriptaculous to allow tags to be dragged to objects?

http://script.aculo.us/drag-and-drop

[Alan Gutierrez]

Sig

I asked somewhere else...

Where's the third party API?

[sig]

Dethe, good ideas, will explore!

Alan, the third party API for interfaces for the main Thingamy system will hopefully be available two to three weeks following the first available V2 version (which of course is days or a few weeks away, said that before...:)

[michael culp]

Just a thought.. How about having tags with nothing under them grey, tags with topcs black and selcted tags in BOLD.

Also if you select a tag have all tags that are not cross referenced to it go grey so you can only choose tags that have something under them.

This is somethign i have been looking for a long time its kind of like the GIA system that nisus came up with for their old mailkeeper program for the mac that has been defunct since the OS 9 days.

[sig]

Michael, you're pin-pointing an issue that is important - how not to be drowned by useless (or rather unused tags :) tags...

My thinking so far is: Tags are not really to be added unless it's actually going to be used.

As a "tag too much" for an object does not matter for its "findability" plus that no object will ever (heh..) be deleted, then no unused tags will exist.

In this test we have the "Add tag" prominently displayed on the front - where it should not be, it should be a pop-up choice when you're in need of one, i.e. when you are about to add a tag to an object. Think that would relieve the problem.

More to come :)

[Jay Fienberg]

Cool--I like it.

But, I think it's mistaken to suggest what you're doing is tree-structure-free. Or, to put that another way: you're enforcing hierarchy in a way that is not required of hypertext links on the web in general (which can be tree-structure-free).

I think this hierarchy in tags is a good and necessary part of tagging. Tagging works because it asserts hierarchy in a way that does not allow hierarchy to overtake a fuller relational structure.

But, IMHO, the whole "it's not a tree" concept requires ignoring the principle hierarchy set by the context (i.e., the website itself being the root node of the tree).

I've written about this in "Tags stuck on trees (with pictures!)"

http://icite.net/blog/200506/tags_trees.html

[sig]

Jay, good point, and interesting article! Although...

A tree-structure requires a precise navigation, multiple-tags-interception are non-sequential and as such requires no navigation.

A tree-structure requires unnderstanding/assimilation of the logic/design of the tree (usually the logic of the object organiser - say a web designer).
Imprecise tagging and interception-of-multiple-tags is less dependent, less and less the more people tag an object and thus applies different logic to the "namespace" (identity, position in tree-structure speak) increasing the chance of my logic will match somebody else or a combination of many.

A link is sequential and requires a precise navigation from top to bottom. And it is linked towards the source, change at source and the link will break. Thus I see links as tree-structural - url, paths, names, titles... all hierarchical and sequential.

A tag is linked from the source and cannot break. It can disappear, or appear as a "link" from an object if the object (and the tag at source) is changed.

When using "interception between multiple tags" you can have an object in multiple "places" in tree-structure thinking, which is not possible as tree-structures requires a two-dimensional positioning (and links criss-crossing the hierarchy falls into same problems as mentioned above; change at source and links break).

Thus I stand by what I said, "anataxonomy" (see post below) as in interception-of-multiple-tags is truly non-tree-structural :)

[Jay Fienberg]

Sig, thanks for your response to my comments. I agree with what you are saying and think it's a good thing.

(Though, I don't totally follow what you are saying about a link as hierarchical / sequential, and am interested in understanding that better!)

But, you are asserting a website as a place where all of this happens. And, in fact, I think what you are doing requires a "place" in which it happens.

This place functions as as the root of a tree. It is a parent that defines the logic/design of what happens within it (the children).

Basically, what I'm saying is that you have a tree upon which you are supporting the anataxonomy.

I don't disagree that you have what you're calling an anataxonomy--and it's fair to call that part of it, in isolation from its context, tree-free.

But, as it actually exists in context, it itself depends on a tree in which it itself is the child. That tree is necessary to establish the authority to the tags--it embodies the logic / design that defines the tags element used for tagging.

[Michael Foong]

Its getting very very addictive. I love the concept of Anataxonomy and Tagging. Creates breathing room for thoughts to naturally flow.

There are indeed a few type of knowledge segmentation, some has cross culture elements and some rather personal. If we mixed it all in one site it becomes a jungle of relationships. How do you handle duplication? or terminologies/slang/etc? Not sure how it will eventually work out but it is interesting to see.. ;)

Maybe the community will eventually subsume, converge together and have a common thought proccess, tagging and relationship to knowledge.

I find this as a very intriguing thought management system and would love using something like this as a personal thought organizer. Are you going to make it open source?

from Michael's desk...

[sig]

Jay,

a link is usually a navigational path like /usr/local/sbin/cvs or thingamy.typepad.com/sigs_blog/2005/07/etc - with root or .com as the trunk, rest being branches. And /cvs/sbin/usr/local or /local/sbin/cvs/usr/ would not lead anywhere or what :)

Your other point is a brainteaser, but let me try: Objects/subjects as we handle them in in these examples are mere representations - "Mary Poppins" in the tagwork is not the film of course. Being human I need one interface to sort and find the representation of the objects/subjects - and it's that structure that can be non-tree-structural.

Funny thing though, SQL DBs are pretty much closer to the tree-structure than OODBs - and tagwork uses (for now) mySql so a layer of "mySql pretends to be OODB" was made. But that will change as we fold it into the Thingamy that has an OODB made for this purpose.