Showing posts with label rose. Show all posts
Showing posts with label rose. Show all posts

Monday, March 22, 2010

Don't Call Names...It IS polite to point!

Mom always said "Don't call names!" and "It's not polite to point!".  Ok, so how am I supposed to refer to "you know who" over there?  Too late! I already "pointed" verbally when I said "over there".  But, not only is that ok for programmers, it is actually preferable to point rather than to use names. And a half-century before computers even existed, Philosophers already knew this.  So why are programmers still calling names?
A bit of background first for programmers...
The philosophical use of the word "reference" (and hence "refer") has a subtle technical meaning that, luckily for us, corresponds with the object-oriented technical term "reference".  In Philosophy, the only way words can say something about the real world is via "reference". In Java programs, the only way to say something about an object is via an "object reference".  In other programming languages it is via a "pointer".  Interestingly, according to the 20th century philosopher Bertrand Russell, the only way one can truly refer to a thing (using language) is via a "demonstrative" (i.e. pointer words like "this", "that", "those", "these").

Contrary to previous thinkers, Russell held that proper names (e.g. Joe Blow) do not "refer".  OOP programmers can relate to this because a reference (or pointer) to a Person object can access that object's properties, but the string "Joe Blow" can not...

Person p = new Person("Joe Blow");   // get an object reference "p"
p.weight = 175; // THIS WORKS!
"Joe Blow".weight = 175; // THIS DOESN'T WORK!

Now, the string/name "Joe Blow" could be used in a query that describes a Person object and returns a reference to it. And WAAAY before computers, Russell said the same thing.  Names are a description of something and not a reference to it.
(Descriptivist) Philosophers declared that names were not references because there are a number of problems in logic that arise if they are.  I have written about several of these in earlier blog posts, but in a nutshell:
  • names can change even though the object doesn't (e.g. maiden names)
  • names can have meaning over and above referencing an object (e.g. Superman vs Clark Kent)
  • objects can have more than one name (e.g. Morning Star vs Venus)
  • names can be given to objects that don't actually exist (e.g. Unicorn)
  • not every object has a name (e.g. that piece of paper over there)
While OOP programmers may know that a pointer or reference to an object is different than a "name",  many database designers haven't absorbed that yet.  Of course, they can be forgiven somewhat because the relational database model does not really give them references or pointers.  The only way to access the properties of an object (aka entity) is via a query (and hence a description).  This has led to the common practice of creating an artificial property (aka surrogate key) that can be made to have a unique, unchanging value for every different object/entity, and is a close substitute for a "reference".

On the other hand, there is also the practice of using the name property of an object (or any other real world properties) as a reference mechanism (aka natural key), and so naturally there is great debate about whether this is ok or not, and when to use one or the other.

Philosophy would counsel (as would I) to not call names (i.e. don't use natural keys), and don't use artificial keys that the world knows about (like Social Security Numbers because even those have duplicates!). Below are a few case studies of problems arising from name calling rather than pointing.  They share a base problem that the natural key data is almost never "essential" in the philosophical sense; i.e. the data is capable of changing over time even though the object is considered to be the same object.

Case Study: Yahoo Bookmarks

It turns out that once a bookmark is created on the Yahoo Bookmarks site, there is no way to change the URL associated with that bookmark.  Someone decided to use the URL as a natural key (which by definition should never change), so, the URL can't be edited.  The problem is that a "bookmark" (by my thinking) is not synonymous with a URL.  It is a marker that enables me to return to a web page.  With web sites being revamped all the time, and most URLs not being "permalinks", the same page can have it's URL change over time.  If I need to update the URL, Yahoo makes me delete the old bookmark, create a new one, and re-enter the name, comments, etc from scratch.

Case Study: Qlubb site names

There is a web portal where one can create free web sites for small organizations (i.e. clubs aka qlubbs).  To create a site, you select a club name and then customize the generic site created for you.  However, in the help page, they warn that there is no way to change the name of your club once it is created because
"We currently do not support the ability to change the Qlubb name as there may be database consistency risks. However, if your Qlubb really want to change the name, please have a Qlubb administrator send a note to help at Qlubb with your request. We will evaluate each request and perform the change manually, if it is safe to do so."
Obviously someone mistook a name for a unique and unchanging key.

Case Study: Semantic Web

For all those programmers groaning at the last example, asking how anyone can still make that old mistake in this day and age, the same thing goes on in the new frontier of the Semantic Web.  In most tutorials on the Semantic Web, or tutorials for logic programming languages like Prolog, and yes, even in my youthful whack at a semantic network database, names of things are confused with references to those things.  As I wrote about the flaw in my SN database back in 2007, this causes real problems in all the ways that Philosophers recognized a century ago.

Wednesday, June 10, 2009

An Adjective is a Noun is a Verb

In my earlier blog entry about Russell's Theory of Descriptions, it gave the example of rewording "The present king of France is bald" into a special descriptive form. You may have noticed in that discussion that the phrase "X is kingly" was used instead of a more natural sounding "X is a king". This is because Russell was attempting, via his special form of making statements, to remove all implicit claims that X exists, to be replaced with mere descriptions of X.
Programmers should think of this as the difference between:
"(x instanceof King) && x.bald && x.french"
versus
"select * from AllThingsTable where french='Y' and bald='Y' and kingly='Y'".
The former would blow up in Java with a null pointer exception if X didn't exist, whereas the latter in SQL would not blow up; it would merely return zero results meaning that none exist.
In philosophy, nouns are reworked into adjectives and even verbs all the time to make statements more precise. In Russell's template, nouns are reworked into adjectives. In process philosophy (where everything is considered a "process" rather than a "thing"), a "king" would really be considered the process of "kinging".

Lest all this awkward wordsmithing seem too artificial, a quick look at McWorter's video introduction to linguistics[1] will show that what seems natural to us, is English specific. He gives the example of "I like Pam", where "like" is a verb, but in Japanese, the equivalent "Pam ga suki" literally means "Pam likeableness". So, a concept in one language may naturally be an activity, but in another language, it's a noun form of an adjective.

[1] Understanding Linguistics: The Science of Language, John McWhorter
- http://www.teach12.com/ttcx/CourseDescLong2.aspx?cid=2270&pc=Social%20Sciences

Monday, April 6, 2009

A rose is a rose is (not) a rose

In several of my earlier blog entries, there was discussion as to whether words like "rose" have meanings, or are only references to things. Shakespeare thought they were only references to things when he wrote "A rose by any other name would smell as sweet". My conclusion to the contrary (based on "salt") has been given empirical evidence, as described in a story on National Public Radio[1].
Lera Boroditsky, an assistant psychology professor at Stanford University, had conducted experiments in which people were shown to be unconsciously affected by the language they spoke when they described things. In languages like German and Spanish that have "gender", each noun (unlike English) is either male, female, or neuter. However, languages aren't consistent with regard to the gender of any particular word. In German, the word for bridge is feminine, and in Spanish it is masculine. When test subjects were asked to provide words describing a picture of a bridge, the Germans came up with fragile, elegant, beautiful, peaceful, slender, and pretty, whereas the Spaniards came up with strong, dangerous, long, sturdy, big, and towering. Even when the test subjects were taught a completely made up language that had gender, they chose descriptions of things that matched the gender of the made up word for that thing.

So, when doing the business and technical analysis of systems, be aware of attached connotations and concept interrelationships before translating rich natural language words like Salary into antiseptic variable names like Foo.

[1] "Shakespeare Had Roses All Wrong", Robert Krulwich

Tuesday, March 11, 2008

Scott is Scott

While reading Looking at Philosophy[1], I came across its discussion of Bertrand Russell's Theory of Descriptions[2]. It was a proposed solution to several problems that occur when logic propositions are made about an entity's existence or identity. One of the problems being solved was that a statement like "Scott is the author of the novel Waverley", if it is true, reduces to the statement "Scott is Scott". This is because in traditional logic, two terms that denote the same object can be interchanged without affecting the meaning or truth of a statement. But since "Scott is Scott" doesn't seem to be equivalent to "Scott is the author of Waverley", Russell proposed that a better way to state the latter was using the template:

There is an entity C, such that the sentence "X is Y" is true, iff X=C.

This would produce the sentence "There is an entity C, such that "X wrote Waverley" is true, if and only if X=C; moreover, C is Scott". What Russell was getting at was that there was a problem with the traditional view that a definite description could be exchanged with a proper name. A phrase describing something (e.g. "the author of Waverley") means something different than a name (e.g. Scott) because while it is true that "George IV wanted to know if Scott was the author of Waverley", it is false that "George IV wanted to know if Scott was Scott". Russell's template solved this problem along with others like making claims about non-existent things. E.G. "The present king of France is bald" is problematic because there is no present king of France. If it were considered false then "The present king of France is not bald" would have to be considered true. This is avoided by saying instead: There is an entity C, such that the sentence 'X is French, bald, and kingly' is true iff X=C. THAT statement is false (because there is no entity that fits that description), and its opposite is true (i.e. There is NOT an entity...).

[1] pg 322, "Looking At Philosophy: The Unbearable Heaviness of Philosophy Made Lighter", 2005, Palmer
[2] Existence and Description, Bertrand Russell from "Metaphysics: an anthology" by Jaegwon Kim, Ernest Sosa - 1999

  

Thursday, January 24, 2008

Word Matters: Words Matter

In my earlier blog entries, I noted the debate over whether words had meanings, or were only references to things. It was noted that while "rose" and "gulaab" work equally well for speakers of English and Urdu, "Superman" was not interchangeable with "Clark Kent". This was because Superman and Clark Kent both referenced different aspects of the same entity instead of both referencing the same entity as a whole.

However, the actual words still didn't matter in that discussion. While Clark Kent was different than Superman, the actual word "Superman" didn't matter...it could have been "Clark Kent is different than Foo" (if everyone called the man of steel "Foo" instead of Superman).

After reading Salt: A World History[1], I've decided that words DO have their own meaning because of all the connotations, and rich web of connections with history, culture, and language, that go along with each. The book is chock full of nuggets like the following (paraphrased):

The first of the Roman roads, the Via Salaria (i.e. Salt Road), was built to bring salt not only to Rome but across Italy. It was important because at times the Roman soldiers were paid in salt which was the origin of the word salary and the expression "worth his salt" and "earning his salt". The latin word for salt (sal) became the French word for pay (solde) and that was the origin of the word soldier.

The book makes it obvious that the word Salt couldn't really be much different given its linguistic lineage. Words DO matter because each has a whole slew of connections to other things, and a past history, because each is part of a naturally evolved language. Words evolve from other words; they were not picked out of the air. There is a family tree of related words just like there is a family tree of organisms with related DNA.

Knowing the rich set of interconnections of words, their origins, history, etc makes a word like Salary carry many connotations that "foo" would not. A whole semantic network of related concepts lights up in my mind with the word Salary that would not have if the word for salt was foo.

[1] Salt: A World History, by Mark Kurlansky, 2002

[Ed. Note - 12/11/12: as per my disclaimers, once I start looking for my epiphanies on the net, I find them. E.G. in this case, see "Lecture 26: Culture, Hermeneutics, and Structuralism". Congrats Bruce, you've just discovered what Gadamer said a century ago: language itself is a historical accumulation, each term carrying its past usages which are part of its meaning.]

Tuesday, December 25, 2007

Shakespeare is (not) Shakespeare

In the early part of the book The Stuff of Thought by Steven Pinker, the problem of what-a-name-names, is explored with the example of Shakespeare. Pinker distinguishes between Shakespeare: the historical figure, and Shakespeare: the author of numerous plays like Hamlet attributed to Shakespeare.

In my earlier post, it was somewhat easy to see that there were multiple aspects to Superman because each aspect already had its own name; Superman vs Clark Kent. With Shakespeare however, it is much more subtle because the different aspects have the same name: Shakespeare. Additionally, we are not used to thinking that they are different aspects that can be independent of each other, any more than we think of Cher-the-person and Cher-the-singer as being independent things. But, as discussed in the book, many people over the centuries have debated whether the author of Hamlet, et al was really Francis Bacon, Christopher Marlowe, Queen Elizabeth, etc.

The interesting thing is that because Shakespeare is SO ingrained as the name of the playwright that even if Sir Francis were to be proven the author, the headline will be "Bacon is the REAL Shakespeare!" which is absurd because clearly, Shakespeare-the-historical-figure is the "real" Shakespeare. Changing the human associated with the author-of-Hamlet concept will not change the concept's name; it will remain "Shakespeare's Hamlet (written by Bacon)" and not "Bacon's Hamlet".

So, when assigning ID#(s) to putatively single entities, flexibility should be built in to allow ad-hoc collections of attributes of any entity to be grouped and named and referenced separately. Otherwise, the system would not be able to represent the statement: Shakespeare is not Shakespeare, Bacon is.






Wednesday, December 19, 2007

Clark Kent is (not) Superman

It delights me to find out that what I thought had been a particular nugget of wisdom, specific to building Identity matching computer systems, actually has a deep principle at work. While working on one of these systems, I learned the strategy of NOT merging all variations of an individual identity's name/address/phone/etc into a single canonical version. It turns out that the need to keep, and assign a unique key to, every variation of identity data (as opposed to only the "canonical" one) has deep roots in language itself...

While reading the Intellectual Devotional (which I highly recommend), I came across its page about "Philosophy of Language" and it had an immediate resonance with a project at my current client. The page describes the "problem of reference" where ideas about what a name "means" have been debated and changed over time.

One theory says that "names" don't have any meaning, in and of themselves, they merely refer to some
thing that has meaning. Hence, Shakespeare's quote "A rose by any other name would smell as sweet" summarizes the position that the word "rose" is not meaningful, and could be exchanged with any other word that refers to the thing "rose". That is why "gulaab" (the Urdu word for rose) can work just as well for speakers of Urdu.

Another more modern theory though, says that names not only refer to some thing, they also carry the connotation of "in what sense" is the thing being referenced. The book illustrates the example of Superman and Clark Kent both being names for the same thing (the being Superman), but they are not interchangeable. Clark Kent (mild mannered reporter) has a work address of the Daily Planet whereas Superman (superhero able to leap tall buildings) does not. It matters which name is used when talking about Superman.

So, in the same way that Clark Kent and Superman both refer to different aspects of the same entity, and are thus not interchangeable, a computer system managing legal entity identity data can not translate name/address variations into a single entity ID# when those variations actually refer to different aspects of the entity. For example, if there is data that is specific to a particular store branch, that branch needs its own well-known ID# even though it is only a portion of a single legal entity. Further, since legal entity names are not unique (for example, I personally own two different corporations with the identical legal name), the entire name/address/phone/etc combination needs managing rather than separate "alternate name" lists. It is also not sufficient to support alternate name/address records merely as search aids that still ultimately result in the ID# of the entity-as-a-whole. Otherwise one would loose track of the fact that we were talking about Clark Kent, not Superman.