[Design] RE: About Organizing Information Using Browser Bookmarks
Mimi Yin
mimi at osafoundation.org
Mon Aug 8 09:02:55 PDT 2005
Please see comments in-line...:o)
>> It brings us to the fundamental problem of things being "too
>> generic." Tags are too generic, just as the notion of "related tags"
>> are too generic. Both beg the same sort of questions:
>>
>> How does this tag apply to this item? (This is another way of saying
>> that you want to be able to tag the tags with attribute names.)
>>
>
> Although Jon Udell seems to be getting a lot of mileage out of the
> mere
> fact of relatedness, according to some of his blogs. Of course, this
> relates to serendipity more than to finding just what you want.
I think that's the point. Tags and Search are serendipitous. (And the
best we can hope for is that we might find just what you want.) But
any information or knowledge we extract from the data is by chance as
your rooting around tunneling from one tag to a related tag... It's
more on the level of: "Oh that's sort of interesting, I didn't know
that A was related to B" and less of a more global understanding of
how the data and tags fit together. It's essentially the difference
between running a maze from the perspective of the mouse or from the
perspective of the scientist observing the mouse.
>
>
>> Toes and Toenails are dependent facets and therefore can be construed
>> as having a variant strain of Parent-child relationships. All things
>> that have Toenails also have Toes, but all things that have Toes,
>> don't necessarily have Toenails (I'm not actually sure if this is
>>
> true.)
>
> The question is whether knowing those things matters much when I
> need to
> find something in my collection of information. Or, for that matter,
> some other collection, which may be aggregated (I tend to take the
> attitude that I should first try to create a system that works well
> for
> my personal stuff, because if I can't do that, how in the world can I
> ever expect to do it for an aggregated collection that isn't just
> mine?).
Yes, if the system's goal is "targeted search and retrieval" of
individual items, I agree, understanding the intricacies of all the
different ways things are related to each other is not important. My
proposition is that in order to get anything MORE out of your data,
relationship types is crucial.
>> "Email 1" and "re: to Email 1" is yet another type of relationship
>> that is neither Parent-child, nor facet, although it is usually
>> modeled as a hierarchy. Instead it is a thread relationship where
>> ordering is of primary importance, but the items themselves are on
>> equal or sibling footing.
>>
>> I think differentiating between these different types of
>> relationships is crucial for helping people understand the varied
>> nature of their information and how they relate to each other.
>>
>
> I'm coming to think that the "thread" metaphor ought to be used more
> widely than it is. But the nature of the threadedness is what
> needs to
> vary. I've been remembering the old days when I used to write
> everything down chronologically in my notebook at work. I could
> always
> find anything (eventually!) by leafing through it, and I usually had
> some notion of the context, if only by time. If only I could have
> taken
> those notebooks, and added extra links to any part - say, a paragraph,
> to get a reasonable granularity. Then I could reorganize the
> material,
> annotate, tag, all kinds of things.
>
> There could be all kinds of threads besides temporal. It's really the
> notion of "order", isn't it? I think this is basically about finding
> and displaying a partial order.
>
Yes, I wholeheartedly agree, ordering, not time is what's important
about threads. Conversation threads are just one example of this.
Task dependencies are another.
> Well. I'm, just talking off the top of my head right now.
>
>
>> In truth, in the "real world" there is no such thing as the generic
>> "isRelated" relationship. Whenever humans talk about relationiships,
>> there is always some context to the relationship to make it
>> comprehensible. It's only when we're "fuzzy" about why 2 things are
>> related that we resort to generic descriptions: "I don't know why,
>> but in my gut, I feel like these two things have something to do with
>> each other."
>>
>
> Well, take a mind map, for example. The nature of the
> relationships of
> the items is not stated, it is just there by implication, or by
> association on the part of the viewer. That's why a mind map is a
> lossy
> device - the underlying relationship particulars are lost. That's why
> you cannot go from a mind map to an ordinary semantic network model
> (e.g., rdf). Yet they are very useful.
I question the usefulness of mindmaps. I feel the amount of screen
real estate they take up doesn't justify the scant about of
information they provide....precisely because of the lack of
semantics. If the mindmap doesn't explain why things are related by
assigning significance to the relative position of things on the
screen, then what's really the difference between a mindmap and
simply a list of "related" things (a la delicious).
>> I think this is actually what happens to all of us, even when we
>> interact with software we're reasonably happy with. But this is only
>> because we don't really expect very much out of the software to begin
>> with. We don't really expect to be able to wrap our heads around all
>> that data and understand what it all means at a high level. We're
>> satisfied if we can just click around and find the one thing we
>> thought we were looking for and maybe chance upon something
>> interesting and related along the way.
>>
>
> But we're often in the position that we actually don't know how to ask
> for what we want, even though it may be pretty clear to us. How about
> "that picture of my daughter that I took back ... when was it ... a
> couple of years ago at her graduation dinner ... the version where I
> brightened it up a little... the light level was low, and I remember
> that my father was kind of blocked out by her arm"?
I think again, I'm talking about something different from the ability
to "find" things by context. It's more akin to the kind of knowledge
people try to get out of data analysis: discerning patterns and
correlations that can provide you with an objective view of your life
through the digital residue of the data you receive, create and
interact with. Which in turn, can help you make strategic decisions
about your life and work. It's what software like Microsoft Project
is *supposed* to help you do, but the hope is that we can accomplish
something similar with a much shallower learning curve and effort ramp.
> I better stop spooling out my thoughts here, since I don't really know
> what the goals of Chandler are in this area! When I have a better
> sense
> of them, perhaps I'll be able to be more helpful.
Not at all, this has been a really constructive discussion. But I
appreciate the sentiment!
Mimi
More information about the Design
mailing list