Absolutely, Holes are Relative

This blog is normally about what computer programmers can/should learn from philosophers. Occasionally though, there is a posting like this about what philosophers can learn from programmers...

In An Introduction to Ontology[1], there is a discussion about whether holes “exist” (where “exist” has a technical Philosophical meaning). In laying out the pros/cons of defining a hole as a region of space, the (fatal?) flaw with the approach is claimed to be that, when the thing that had the hole in it (say a pair of jeans) moved to the next room, the hole wouldn’t/couldn’t move because it was defined as a particular region of space.

I, as a computer programmer, am left dumbfounded that anyone would make the definition of a hole be an absolute region of space, any more than they would define the geometry of each leg in the jeans as being an absolute region of space.

As modeled in typical vector drawing logic, the legs and the hole would each simply be a “part” of the jeans entity. Each part typically has attributes defining its contents (often simplified to just its color), so the left leg is denim/blue and the hole is void/transparent. Alternatively, the hole can be thought of as a “subtractive” part which simplifies the description of the geometry of things that have holes. (Beware of saying “that just simplifies the math but it isn’t real” because that's what they said when Copernicus noted that the math was simpler if planets orbited the sun rather than everything orbiting the earth).

CAD/CAM systems often model things as having parts known as features[2], which include not only subtractive “passages” (two openings, i.e. holes), but also subtractive “depressions” (one opening, i.e. dents) and subtractive “voids” (zero openings, i.e. completely enclosed). These are in addition to additive “protrusions”, “connectors” and “stand-alone volumes”. Don’t think a protrusion is an entity (or at least a part)? Don’t peninsulas exist?

So, just as no one has a problem with saying that the leg part of the jeans is a cylinder whose location is relative to the parent jeans, there should be no problem saying that the hole is passage relative to the parent left leg (just over the knee). After all, isn’t a hole always a hole in something? (yes, I know there is philosophical debate about this, like everything else).

The real head-scratcher, for me, is why it is apparently so non-obvious to the philosopher, that the textbook on this stuff simply ends the a-hole-is-a-region-of-space discussion with “this theory gets it thoroughly wrong”. There is no mention of “you know, there is a trivial rebuttal to that objection”. But that is why occasionally this blog has posts about what Philosophers can learn from Programmers.

[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] Parametric and Feature-Based CAD/CAM, Shah/Mantyla, 1995, Section 7.3.1 Form Feature Schema

It's about Time, It's about Space

A 1960s TV series theme song began, "It's about time, it's about space...". Some, from Physics to Philosophy, say it's about both, claiming they are each aspects of a single space-time. Computer systems developers need to consider this as they build GIS applications.

Ontology, being the branch of philosophy concerned with describing "what exists", tackles the topics of Space and Time since they are often used to describe things. An Introduction to Ontology[1] devotes a chapter to each. As usual, things are more complicated than our initial intuition expects, and debate continues about different viewpoints. In a nutshell, the following are discussed:

• Space is usually defined in terms of "regions"
• Space is either absolute or relative.
• Space is either something things "are in", or it is synonymous with the thing itself
  i.e. regions only have properties like size and location, versus, a region itself having the property blue if the stuff in it is blue.
• Space is either Euclidean or not (i.e. flat or curved)
• Space is either separate from Time, or parts of the same thing: space-time.

Most programmers today, in the age of Map apps, Geographic Information Systems, and geocoding, take the view that an entity such as a business or address is located at some location. The location ideally could be defined as a collection of regions defined by GPS coordinates. Often, the location is (over)simplified to a single point on a map.

While it is recognized that many problems exist with actual databases of geocoded entities, it is usually assumed that they are in the realm of epistemology rather than ontology. In other words, it is assumed the problem is with "our knowledge" due to inaccuracies in the set of GPS coordinates; not that locations don't actually have a definite set of coordinates.

However, not every entity that takes up space has a well-defined and unchanging mapping to a set of GPS coordinates.  ZIP codes, for example, are not defined in terms of geography but rather as collections of delivery routes. Another example, as shown in the title insurance case study below, is in real estate legal descriptions. In addition to a knowledge problem caused by ambiguous language used in these descriptions, they can also refer to ephemeral landmarks.

While a naive assumption that space is different than time is often made in data model design, entities like ZIP codes and Legal Descriptions require a time dimension to be completely accurate. It turns out that the mapping of zip codes to postal routes changes several times a year.  And landmarks, referred to in property descriptions, can change location and shape over time.

Case Study: TICOR Title Insurance System

OMEX was a startup that was an early pioneer in creating optical disk technology for data storage. It took on a contract to produce a computer system to support TICOR, the largest title insurance company in the U.S.  TICOR itself had the contract to keep backup copies of all the real estate transactions filed with Los Angeles county.  As a part of archiving copies of the documents, it was free to use the information in them, and hence support its business of providing title insurance.

The computer system was to replace using microfilm photos of the documents with optical disk storage of the images.  It would link these images with a structured database of information related to each property. One of the goals of the database was to enable answering basic questions about property locations.

The programmers, having a naive notion of how property boundaries were defined, were surprised to see that a common method is “metes and bounds” which uses plain english descriptions using landmarks. E.G. "beginning with a corner at the intersection of two stone walls near an apple tree on the north side of Muddy Creek road one mile above the junction of Muddy and Indian Creeks, north for 150 rods to the end of the stone wall bordering the road, then northwest along a line to a large standing rock on the corner of the property now or formerly belonging to John Smith, thence west 150 rods to the corner of a barn near a large oak tree, thence south to Muddy Creek road, thence down the side of the creek road to the starting point."

As can be seen, it would be difficult to translate this into a collection of GPS coordinates. But even if you did, you would not be done with the problem.  Like ZIP codes that change over time, the location and shape of creeks, rivers, etc change over time. Lest you think this is a merely theoretical problem, for centuries, States have sued each other over land ownership due to border rivers migrating over time.

Ultimately, the computer system wound up just using unstructured text fields to contain the legal description rather than the more ambitious GIS database they had originally promised.

[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013

[2] A River Runs Thru It, How the States Got Their Shapes, History Channel, 2011