Namespace paradigm and lexicon

Analogy: labeled tins of food in a cupboard with two shelves, which are also labeled. Labels are bits of paper stuck to the tins, or to the edges of the shelves.

Label = name Object = tin (or its contents) Namespace = a shelf, with the tins on that shelf.

On the shelf labeled "Food for me", a tin labeled "Chicken" most likely contains bits of tasty chicken. But someone might have switched labels, for a prank, or because the labels came of in humid weather, and were stuck brack on the wrong tins. (The Unix "lost+found" directory contains tins with no labels.)

On the shelf labeled "Food for my farm animals", a tin labeled "Chicken" most likely contains chickenfeed, which (ones hopes) does not contain bits of chicken.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

The problem is that it was *wrong*. Overall productivity INCREASED when the typewriters stopped jamming.

No, it is very different. The iconography is to accommodate people who can't read the working language. It is understandable to a point ... aiding tourists and such with simple to understand signs ... but it should be a crime to use it as a substitute for education.

George

Ha! Interesting approach -- and I see the logic behind it.

I suspect I will have to resort to something more mundane (e.g., people and pets) for a familiar explanation. This lets me illustrate how an object can have multiple names (Niklas, Mr. Holsti, Dad?, etc.). And, how a name in one namespace can be different from a name in another namespace -- yet refer to the same object (e.g., if you are a military officer, one of those namespaces might see you called "Sargent", etc.)

It will also allow me to draw attention to the different range of names that are applied to different *types* of objects (disjoint namespaces). E.g., you might call your dog "Fido" but *probably* don't have any

*friends* that go by that name! :> OTOH, you might have a pet called "Nikky"(?)

(sigh) I had hoped not to need a verbose example but I can't see any way around it. I'll have to think carefully bout the terms I use to reference the concepts, here (aliases, nicknames, naming, REnaming, etc.)

8<

It needn't even be that "general". E.g., you could tabulate the name recognized in each particular namespace and let the user *pick* from among them, etc.

Rather, the important thing is that namspaces can overlap, can be disjoint, can contain aliases, etc. I just want to get people away from the "unified namespace" that they are exposed to in filesystems and highight the other possible "operators" that can be applied to names/objects. I.e., creating an alias creates a *name*, not an "object" (ignoring the fact that names are also, technically, objects in their own right)

"Context" is a great word! It highlights the fact that names can mean ("refer to") different things in different "situations" (contexts)

s "

It seems to me that 'tags' in the current sense of the word and/or Venn diagrams might help in part of the explanation. Dunno how you would introduce any 'changeability/dynamics' into the model.

What's the difference between an overlap and an alias?

Like {the namespace of this USB flash drive} and {the namespace of that USB flash drive}?

Like shortcuts?

What makes you think that they are? I'm not challenging your findings, just curious for your methods and the demographics of the results.

Thanks.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)

QWERTY was a band-aid to compensate for a poor implementation of the typing mechanism. It improved the apparent performance of the *mechanism* at the expense of saddling the user with the cost of that. I.e., other keyboard layouts were equally feasible that wouldn't have burdened the user *if* a better

*mechanism* design had been used. It's like adopting a time_t representation that you *know* will break in *your* lifetime!

That argument applies to things like signage, not the "menubar buttons" to which I was referring. Those sorts of signs tend to have very simple meanings which are fairly obvious in their context. Things like traffic signage can easily and unambiguously represent things that *seem* complex but which really aren't. E.g., even folks who've never navigated a rotary (traffic circle, round-about) can figure out what lies ahead with a graphical depiction of the intersection.

OTOH, trying to come up with symbols/icons to indicate "insert cross-reference marker, here" or "lookup this word in thesaurus" get to be too much of a stretch, IMO.

I've encountered bathroom icons that tried to be *too* clever -- requiring you to see *both* alternatives before deciding which *should* apply. :<

[elided]

An alias is a duplicate name for an object. I.e., I might be called Don, son, brother, Mr Yuniskis, "the guy across the street", etc. One object (i.e., me) referenced by several "equivalent" names. These names can all coexist in the same namespace *or* be spread among multiple namespaces.

Overlapping namespaces allow certain names to have meaning in different, disjoint namespaces. E.g., the namespace that my neighbor uses to refer to the people he knows contains a "Mr Yuniskis" that refers to me. Likewise, the namespace that my alma mater uses to reference its alumni *also* contains that same name *and* it also happens to refer to me (a consequence of having an unusual last name?).

A particular name can have *different* meanings (mappings?) in different namespaces. E.g., "the guy across the street" would mean something different in a *different* neighbor's namespace (e.g., the neighbor who lives next door to me).

Note that overlaps and aliases can coexist -- i.e., my neighbor also knows me as "Don".

Yes. In that case, there is *no* overlap (since the objects on drive 1 are not the *same* objects as on drive 2 -- even though some might be intentional

*copies* of their counterparts on the other drive.

But, they needn't be physically disjoint. For example, two users of single, shared computer can have lots of commonly accessible "files" (e.g., "\Program Files\...") yet the two users will have *different* namespaces -- "My Documents" will have different contents for User1 vs User2.

More *subtly*, those two users could each have "John Doe" in their address book -- the *same* "John Doe". (Note that this need not be two *copies* of "John Doe's information" if the system has a means of allowing each user to *link* to a shared SINGLE INSTANCE of "John Doe")

I dislike the term "shortcut" because it brings up MS imagery. I don't know enough about their implementation of "shortcuts" to know if a shortcut is effectively identical to a filename.

A better example is link(2)-ing another name to an existing "file" (UNIX). There, neither name is "more correct" than the other. E.g., if I create a file called "foo" and then link "bar" to that same file, neither "foo" nor "bar" is "more correctly" the name of the file. They are equivalent names for the same file. And, if I "delete" (unlink) "foo", the file still remains (even though it was initially *created* as "foo"!) but now can only be referenced using the name "bar". Likewise, deleting "bar" would have left the file intact -- but only accessible as "foo".

It is my understanding that shortcuts are more like symbolic links (symlinks) in that they have to be "interpreted". So, if you create a shortcut to "foo" (called "bar") and then delete *foo*, that shortcut still "exists" but it doesn't *work* (i.e., when it is "interpreted" at some future time, "foo" will be discovered to be absent). This differs from the "hard link" behavior, above.

People see different types of objects as files with special "extensions" ("file types"). They experience every object in a single arena -- the hierarchical file system. They *know* that "address.bk" is a file somewhere on the computer. They know that "vacation.jpg" in "My Photos" is also a file hiding somewhere.

Namespaces allow the namespace creator/maintainer to define *what* goes in that namespace. E.g., you wouldn't expect to find Vacation.jpg in your "address book". People think of names in an address book differently from "files" in the filesystem. Yet, all are "named objects". It's just that the designer of the address book namespace imposed a structure on the types of objects that could be *referenced* within that namespace. I.e., they all represent contact information for "entities" (which may not even be "people")

But, the address book implementor had to re-implement the same sets of functions for manipulating that special namespace -- "create contact", "delete contact", "rename contact", "list contacts", "sort contacts", etc. Each of these manipulates the namespace and its presentation. Just like "create file", "delete file", etc. do in the "filesystem namespace".

As I said initially, people are already familiar with these ideas. But, they don't see them "generalized". They see contacts (and the operations performed in their support) in an address book different from files in a filesystem. I'm trying to extract and *abstract* that aspect of naming so that *it* is most obvious. So people don't "think twice" about the idea of an object having multiple names and/or different contexts.

Hopefully, getting that out of the way will let them see other aspects/characteristics of the objects themselves. And, appreciate how namespaces can work in ther favor.

E.g., instead of having an "attribute" on an address book record that indicates whether it is "private" or not, imagine a separate *namespace* in which all private "address book objects" reside! Now, you don't have to write code to add that attribute to each object. Nor code to allow objects to be sorted/displayed based on that object (i.e., "show me all of my private contacts" or "show me all of the contacts that someone else *might* be able to examine because they are NOT private"). Nor code to manipulate that attribute. Instead, you just exploit namespaces and operations thereon -- move a contact into or out of the "Private" namespace, etc.

[Note how the "private" and "nonprivate" namespaces have no overlap. Yet, an "all_contacts" namespace containing *aliases* or every contact -- regardless of which of the private/nonprivate namespaces in which they reside -- can completely overlap BOTH of those namespaces! And, once the user recognizes that these are just 2N names for the N contacts, they implicitly know that the entry for "Don" in "all_contacts" does *not* need to be updated when the phone number for "Don" in the "private" namespace is modified!]

Yes -- Venn diagrams! Though they needn't be as "abstract" as in an intellectual sense. I.e., clouds containing "names" that point to depictions of "people".

Adding an alias just adds another entry to a cloud (namespace) and an arrow pointing to an *existing* object. Renaming is illustrated by a before and after illustration of the names/bindings.

The "flavoring" of a namespace can be illustrated graphically as well. I.e., the "objects" referenced in address book namespaces are instantly recognizable as "people" (small fib); the objects referenced in an accounting ledger are checks or deposit lips; the objects in MyTopDeskDrawer can be a collection of assorted odds and ends (i.e., what they have in common is simply their *location*).

That's a straw man argument ... a "better" typing mechanism didn't exist. There were a dozen or more competing mechanisms, all of which failed miserably in the market because they were unreliable. Shole's and Glidden's 1868 design - which helped established QWERTY as the standard keyboard - caught on because it worked.

It wasn't until electric typewriters in the 1920's that mechanisms were quick enough to tolerate more efficient keyboards. By that time it was too late.

Few people - and no businesses that want to stay in business - care about what might be theoretically best. They care about what works well enough.

I think I said as much.

George