Tag World
As in the BYO project page, we begin with an atomic concept that is simple and general: simply a unique ID, an author, and a time of creation (and sequence number, just to be safe ;-). A meaningful item must also have some content which would typically be some text, an image, a sound, a link, etc.
This is another take on the earlier experiment at http://lively-web.org/users/Dan/BYO.html. That one focused on a simple collaborative kernel, and a simple way to build up meaningful objects in a database that is synchronized among several users.
Stop reading here. This last paragraph is here because cmd-return does not work to append at the end, so this paragraph assures that none of the others are at the end and cmd-return will work for them ;-).
As in the BYO project page, any item can probably have properties added to it to be more useful as, eg, a sticky note, calendar item, a contact item, or an email. Some properties are atomic, such as a tag, "family", and some may have associated values such as "date" for a calendar item. Some properties may be collections or ranges, and we'll try to do a nice job of that before we're done.
Properties
The Item
About this page
This attempts to build up a meaningful information store using nothing but tags. This is indirect opposition to our (Smalltalk, Lively) LISP-like approach of working with pointers, collections, classes and mutable state. Here are some aspects to this approach that I hope will turn out to be of interest...
Tags
The current topic is a kind of "turtles all the way down" investigation into whether we really need anything other than tags and, if so, what's the simplest generalization that does the job.
Let's suppose I want to start writing about various projects I've done, am doing, or want to do. In each case I consider the essence to be a simple text that describes the project. Actually the essence might be a thing or a picture but, for the purposes of this investigation it will be nice to have some uniformity in our representation.
A scenario or workflow...
1. I think it is how the mind works. We get experiences (sights, sounds, feelings, communications, internally generated ideas, ...), and we classify them. We cannot destroy our data, but only add to it.
2. For this same reason, this model fits with the Notebook model of a time-ordered write-once store. Instead of changing the past, we can only revisit it and explore new directions as a fork.
3. While I'm surely not the first to explore this, it is intriguing to rethink collections, classes, inheritance, etc. as made of something simpler.
4. It feels as though this offers a bridge between the computer science-y, LISP-y world and the database world, and it might be interesting to revisit programming in that context. In our daily life we use a map-reduce so naturally, it's likely the brain works this way as well
So as a start, I would copy a sticky note, and type the name of my first project, "DRACULA - A calculator using logarithmic arithmetic". Then I would copy a tag, such as "Poem", and edit it to say "Project", and stick it on the descriptive note.
I'm not sure about layout issues for tags, etc. For now I think a note should have two states - showing tags or not, and maybe an indicator that there are tags when they are not showing. But chances are, everything will have tags before we're done, so this may be silly. And the tag space may get quite complicated since, if there is nothing but atoms and tags, then the whole ontology must somehow be encoded in the tags.
Then I would probably like to tweak the appearance of this project note - make it green, with rounded corners and maybe a gradient fill. I'd also like to somehow assert that this is a view of choice for this instance and instances like me.
With that thought in mind, now I might make a whole bunch of copies of that project item, which would include the project tag and the visual adjustments that we just made.
I'm not quite sure how I want the DB access to work at this point. I think I would like to be able to hit the X icon on any of the project items and they would go away, but remain in the database. In other words they are preserved by default, although they can always be expunged if not wanted (but of course this is only effective from this time forth - they remain in history ;-). [side note: What is the status of expunged items with regard to search? Presumably search has context and the default sees only items still in existence].

Now let's suppose I have as one of my projects the BYO Collaborative Data Experiment, and I want to describe it and add a team...
There are lots of ways one can think of handling description. One could copy a primitive note, tag it as "Description" and drop it on the Project item. If many such notes were added, then a retrieval of description within the context of that project (er, how do we do that?) would yield all of them in creation order as a default.
Or one could copy a collection item, tag it as description and drop *it* on the project. Then one could drop a bunch of primitive notes onto the description collection of the project.
A good question is whether we need a collection item to do this. Why couldn't an entirely blank item accept multiple drops, with the semantics of growing a collection.
We would like this same approach to work for the team. We copy an empty item, tag it as "team", drop some people on it, and then drop the team thing on the project.
But this is not the only approach since, by analogy to the "Description" items above, we could have tagged the people as "TeamMember" and then dropped them directly onto the project.
So here we have two different general approaches: Make a container for (or concrete representation of) a collective property (described by a tag) and then add items to it, versus making a tag for the property and adding it to every member added directly to the project. Descriptive paragraphs and team members are two examples of this choice arising.
Implicit in the first option is the idea that things can be added to other things and they automatically become members in some unnamed property associated with that thing. In the team example, the team thing is tagged as such, and its members are simply things that got added to it. If we tried to add a location to the team, this simple approach would not work as the various elements of the team would hav to be differentiated.
In addition to this current dichotomy of attributed collections vs attributed elements, there is still the somewhat more normal approach of declaring property names rather than tagging added properties. Why not just go with that normal approach? The reason, which is still a bit vague for me, is that tagging seems a bit more declarative and more late-bound. The normal approach requires that a master instance be created in advance of adding a property, and requires attribution of the role of that property, in a way. The tagging seems to admit of a sloppier style where one could just throw a bunch of things together and later sort out (by tagging) what exactly the organization is. Also it seems (thought I'm not sure of this) that it requires less built-in functionality in the architecture.
DB
Filters
Results
Here is a thought...
X
C
-
Poem
Project
Workspace
X
–
Menu
Things to fix...
X
–
Menu
Yet to do...
X
–
Menu
A couple of things to try...
X
–
Menu