Once a Pioneering ‘Telecommuter’, I Have Now Worked from Home for Two Decades

We had a party this week to celebrate my daughter and her boyfriend’s career move to Seattle. It was a great time with many reminiscences of our life here in Iowa City over the past decade. Then it struck me: almost to a day I had now been working from a home office for 20 years!

Wow. I had not really been paying attention. That realization in turn brought back its own memories, and caused me to reflect back on my two decades of working from home.

Why and the Enabler

I left my position as director of energy research at the American Public Power Association in early June 1989. We were just a month away from my son’s birth and had decided we did not want to raise our children in Washington, DC. The District at that time was totally dysfunctional and had earned the moniker of “Murder Capital of America.” While we loved our home in Barnaby Woods (Chevy Chase) DC and our neighbors, we wanted a smaller and safer community with more connectedness.

My wife, at that time a post doc at the National Institutes of Health in Bethesda, also was committed to her profession and career. The Washington area was unlikely to be an immediate prospect for her to find a permanent position. Indeed, our generation was just coming to grips with the new challenges of two professional families: There needs to be career choices and flexibility between the partners. Some professions, like lawyering or doctoring or sales or computer programming, have much locational flexibility. Others, such as bench scientists in biology, as for my wife, less so. In academia, position openings occur at their own place and time.

I had also been climbing my way in a corporate and office environment for more than a dozen years and was ready for my own career change. As a professional, I had never been my own boss and wanted to see how I could fare in the consulting and entrepreneurial worlds. By doing so, I could also bring flexibility to my wife’s locational options for her career.

At that time, without a doubt, the enabling technology for my new career shift was the fax machine. The ability to interact with clients with documents in more-or-less real time was pivotal. My first fax machine was a Sanyo thermal model (can’t recall the model now; it is long gone and they have since gotten out of that business). I recall buying cartoons of thermal fax rolls frequently and the copies that faded in the file cabinet drawers.

Of course, the phone and plane were also pivotal. In the early years my monthly phone bills were astronomical and I flew around 100,000 miles per year. But, it was the fax that really enabled me to cut the locational knot. But how strange: from thousands upon thousands of faxed pages in the early years to only a few per year today! The Web, of course, has really proven to be the true enabler over the past decade.

Early Lessons

Prior to shifting to a home office it took me about 45 min to commute or bike to APPA. If taking public transportation, I had to walk to the local bus stop, transfer at the Metro subway station, and then walk the remaining distance. While this gave me time to read most of the the morning Washington Post, I knew that by eliminating this commute I could save 90 min a day for new productivity.

What first surprised me, though, was the fact that I also no longer needed to keep my office computer and home computer synchronized. Since, like most ambitious professionals, I also worked some in the evenings, I had overlooked the time it took to keep files and documents synchronized. I was saving about another 30 min per day in digital transfers between home and office. With this new choice to work from home, I was saving 2 hrs per day!

I only had a home office in DC for a short period before we moved to Montana. Since Montana, I have had only two further offices (homes).

My early experience in DC suggested I wanted a more dedicated office space, so we did so for the home we designed in Montana. I was also able to design reserved office space again for here in Iowa City. (The DC home office and the interim one in South Dakota prior to Iowa were converted bedrooms, definitely not recommended!)

Planning office space in advance means you can tailor the space to your work habits. For me, I want lots of natural light, a view from the windows, and lots of desk and whiteboard space. I also needed room for office equipment (copiers in the early years, fax, printers and the like) and file cabinets. When in Montana, I designed up and had built my own office furniture suite that makes me feel I’m commanding the bridge of the Starship Enterprise (see pictures of my current office).

Teaching myself and the kids that office time and office space were fairly sacrosanct was important, too. Sure, it was helpful to be around for the kids for boo-boos and emergencies and dedicated kid’s time, and to be able to be there for home repairs and the like, but for the most part I tried to treat my office as a separate space and to have the kids do so, too. Frankly, since my family has grown up with no other experience than Dad working from home, it has always felt natural and been a matter of course.

A real key is to be able to shut the office door and return to normal home life in the rest of the house. And, of course, the need for the opposite is also true. It is probably the case that I spend more time in my home office than most regular professionals do in their organization’s office, but my career has always been my passion anyway and not what I consider to be a job.

In the early years I was fairly unusual, I think, for working from home. I certainly gave many local talks and was frequently invited by service organizations to speak over lunch on the experience of “telecommuting”. Today, working from home is no longer unusual and the Internet technology and support to do so makes it a breeze.

I have been able to run both consulting and software development companies from my home office over the years. I have seen the gamut of meetings ranging from with developers before massive whiteboards in my home basement to running and coordinating 20-person companies in their own office space with investors and Boards.

With a willingness to travel, it seems like all organizational possibilities are now open to the home worker. For quality of life and other reasons, the fact that today many larger knowledge organizations offer remote office centers and commuting flexibility speaks volumes to how far “telecommuting” has really come.

How much difference two decades can make!

Today’s Thoughts

I personally could never return to a standard office setting. For me, the home office with its flexibility and productivity and ability to find contemplative time simply can not be beat.

I really welcome what is happening in online meeting software and other Web apps that are reducing the need for travel and face-to-face meetings. For while the technology and culture has improved markedly to support working from home over the past two decades, the pain and hassle of travel has only worsened.

I have transitioned from a million-miler frequent flyer to a rooted house plant. I try to chose my travel venues carefully and when I do travel I try to do so for longer periods to absorb the shocks. It is perhaps a too frequent refrain, but it is just a damn shame how getting a meal, being treated with pleasure and courtesy, having some legroom, and getting a drink are air travel amenities of a now bygone era.

There are now many, many more of us (you) who work from home and it really is no longer a topic of conversation. A quick search tells me perhaps 5 million or more US workers predominantly work from home, with some 15% of all workers doing so on occasion. In the predominant professional and business services, financial activities, and education and health services, this percentage can reach as high as 30% of workers now doing paid work from home to one degree or another.

Of course, personality, job requirements, and physical space may not make working from home a good choice for you. But if you have not tried it and it sounds interesting, by all means: Try it!

For twenty years, it has been a great choice for me and for my family. This is indeed a nice 20^th anniversary to celebrate!

Major Report Signals the Emergence of Linked Data into the Enterprise

PricewaterhouseCoopers (PWC) has just published a major 58-pp report on linked data in the enterprise. The report features insightful interviews with many industry practitioners as well as PWC’s own in-depth and thorough research. I think this report is a most significant event: it represents the first mainstream recognition of the potential importance of linked data and semantic Web technologies to the business of data interoperability within the enterprise.

This entire issue is uniformly excellent and well-timed. PWC has done a superb job of assembling the right topics and players. The report has three feature articles interspersed with four in-depth interviews. The target audience is the enterprise CIO with much useful explanation and background. Applications discussed range from standard business intelligence to energy and medicine.

The emphasis on the linked data aspect is a strong one. PWC puts twin emphases on ontologies and the enterprise perspective (naturally). This is a refreshing new perspective for the linked data community, which at times could be accused a bit of being myopic with regard to: 1) open data only; 2) instance records (RDF and no OWL, with little discussion of domain or concept ontologies); and 3) sometimes a disdain for the business perspective (as opposed to the academic).

PWC has done a great job of getting beyond some of the community's own prejudices in order to couch this in CIO and enterprise terms. This signals to me the transition from the lab to the marketplace, with all of its consequent challenges and advantages.

In short: Bravo! This is a very good piece and will, I think, put PWC ahead of the curve for some time to come.

I was very pleased to have the opportunity to review earlier drafts of this major report. After reading a couple of my recent papers on Shaky Semantics and the Advantages and Myths of RDF, with the latter cited in the piece, I had a chance to have a fruitful dialog with one of the report’s editors, Alan Morrison, who is a manager in PWC’s Center for Technology and Innovation (CTI). He kindly solicited my comments and incorporated some suggestions.

The report also lists 14 various semantic technology vendors and service providers. I’m pleased to note that PWC included our small Structured Dynamics firm as part of its listing. Other vendors listed include Cambridge Semantics, Collibra, Metatomix, Microsoft, OpenLink Software, Oracle, Semantic Discovery Systems, Talis, Thomson Reuters, TopQuadrant and Zepheira, with the selected service providers of Radar Networks and AdaptiveBlue.

This report is easy — but important — reading. I personally enjoyed the insights of Frank Chum of Chevron, a new name for me. I encourage all in the field to read and study the entire report closely. I think this report will be an important milestone for the semantic Web in the enterprise for quite some time to come.

After a brief sign-up, the 58-pp report is available for free download.

Ontology Best Practices for Data-driven Applications: Part 2

It is perhaps not surprising that the first substantive post in this occasional series on ontology best practices for data-driven applications begins with the importance of keeping an ABox and TBox split. Structured Dynamics has been beating the tom-tom for quite a while on this topic. We reiterate and expand on this position in this post.

The Relation to Description Logics

Description logics (DL) are one of the key underpinnings to the semantic Web. DL are a logic semantics for knowledge representation (KR) systems based on first-order predicate logic (FOL). They are a kind of logical metalanguage that can help describe and determine (with various logic tests) the consistency, decidability and inferencing power of a given KR language. The semantic Web ontology languages, OWL Lite and OWL DL (which stands for description logics), are based on DL and were themselves outgrowths of earlier DL languages.

Description logics and their semantics traditionally split concepts and their relationships from the different treatment of instances and their attributes and roles, expressed as fact assertions. The concept split is known as the TBox (for terminological knowledge, the basis for T in TBox) and represents the schema or taxonomy of the domain at hand. The TBox is the structural and intensional component of conceptual relationships. It is this construct for which Structure Dynamics generally reserves the term “ontology”.

The second split of instances is known as the ABox (for assertions, the basis for A in ABox) and describes the attributes of instances (or individuals), the roles between instances, and other assertions about instances regarding their class membership with the TBox concepts. Both the TBox and ABox are consistent with set-theoretic principles.

Natural and Logical Work Splits

TBox and ABox logic operations differ and their purposes differ. TBox operations are based more on inferencing and tracing or verifying class memberships in the hierarchy (that is, the structural placement or relation of objects in the structure). ABox operations are more rule-based and govern fact checking, instance checking, consistency checking, and the like. ABox reasoning is generally more complex and at a larger scale than that for the TBox.

Early semantic Web systems tended to be very diligent about maintaining these ‘box’ distinctions of purpose, logic and treatment. One might argue, as Structured Dynamics does, that the usefulness and basis for these splits has been lost somewhat more recently.

Particularly as we now see linked data become more prevalent, these same questions of scale and actual interoperability are posing real pragmatic challenges. To help aid this thinking, we have re-assembled, re-articulated and in some cases added to earlier discussions of the purposes of the TBox and ABox:

As the table shows, the TBox is where the reasoning work occurs, the ABox is where assertions and data integrity occurs, and knowledge base work in the middle (among other aspects) requires both. We can reflect these work splits via the following diagram:

This figure maps the work activities noted in the table, with particular emphasis on the possible and specialized work activities at the interstices between the TBox and ABox.

The Split Should Feel Natural

Whether a single database or the federation across many, we have data records (structs of instances) and a logical schema (ontology of concepts and relationships) by which we try to relate this information. This is a natural and meaningful split: structure and relationships v. the instances that populate that structure.

Stated this way, particularly for anyone with a relational database background, the split between schema and data is clear and obvious. While the relational data community has not always maintained this split, and the RDF, semantic Web and linked data communities have not often done so as well, this split makes eminent sense as a way to maintain a desirable separation of concerns.

The importance of description logics — besides its role as a logical underpinning to the semantic Web enterprise — is its ability to provide a perspective and framework for making these natural splits. Moreover, with some updated thinking, we can also establish a natural framework for guiding architecture and design. It is quite OK to also look to the interaction and triangulation of the ABox and TBox, as well as to specialized work that is not constrained to either.

For example, identity evaluation and disambiguation really come down to the questions of whether we are talking about the same or different things across multiple data sources. By analyzing these questions as separate components, we also gain the advantage of enabling different methodologies or algorithms to be determined or swapped out as better methods become available. A low-fidelity service, for example, could be applied for quick or free uses, with more rigorous methods reserved for paid or batch mode analysis. Similarly, maintaining full-text search as a separate component means the work can be done by optimized search engines with built-in faceting (such as the excellent open-source Solr application).

These distinctions feel obvious and natural. They arise from a sound grounding in the split of the ABox and the TBox.

The Re-cap of Key Reasons to Maintain the TBox – ABox Split

So, to conclude this part in this occasional series, here are some of the key reasons to maintain a relative split between instances (the ABox) and the conceptual relationships that describe a world view for interpreting them (the TBox):

• We are able to handle instance data simply. The nature of instance “things” is comparatively constant and can be captured with easily understandable attribute-value pairs
• We can re-use these instance records in varied and multiple world views (the TBox). World views can be refined or approached from different perspectives without affecting instance data in the slightest
• We can approach data architectural decisions from the standpoints of the work to be done, leaving open special analysis or tasks like disambiguation or full-text search
• Ontologies (as defined by SD and focused on the TBox) are kept simpler and easier to understand. Inter-dataset relationships are asserted and testable in largely separate constructs, rather than admixed throughout
• Relatedly, we are thus able to use ontologies to focus on the issues of mappings and conceptual relationships
• Instance records can often be kept in situ, especially useful when incorporating the massive amounts of data in existing relational databases
• Instance evaluations can be done separately from conceptual evaluations, which can help through triangulation in such tasks as disambiguation or entity identification
• It is easier to convert simple data structs to the instance record structure, aiding interoperability (a subject for a later part in this series)
• We provide a framework that is amenable to swapping in and out different analysis methods, and
• It is easier for broader input when the task is adding and refining attributes rather than internally consistent conceptual relationships.

Here is a final best practice suggestion when these ABox and TBox splits are maintained: Make sure as curators that new attributes added at the instance level are also added with their conceptual relationships at the TBox level. In this way, the knowledge base can be kept integral while we simultaneously foster a framework that eases the broadest scope of contributions.

Ontology Best Practices for Data-driven Applications: Part 1

Structured Dynamics is plowing virgin ground in how linked, structured data — powered by the flexible RDF data model — can establish new approaches useful to the enterprise. These approaches range from how applications are architected, to how data is shared and interoperated, and to how we even design and deploy applications and the data themselves.

At the core of this mindset is the concept of ‘data-driven apps‘, with their underlying structure based on ontologies. Over the coming weeks, I will be posting a series of best practices for how these ontologies can be designed, constructed and employed, and how they can shift the paradigm from static and inflexible applications to ones that are driven by the underlying data.

So, as the introduction to this occasional series, it is thus useful to define our terms and viewpoints. Clearly the two key concepts are:

• Data-driven applications — this concept means the use of generic tools, applications and services that shape themselves and expose capabilities based on the structure of their underlying data. Generic means reusable. Unlike inflexible report writers or static tools of the past, these applications present functionality and are contextual based on the structure of the underlying data they serve. The data-driven aspects results from proper construction of the ontologies that describe this underlying data
• Ontologies — ontologies have been something of a teeth-grinding concept for a couple of years, having been appropriated from their historical meaning of the nature of being (“ontos”) in philosophy to describe “shared conceptualizations” in computer science and knowledge engineering [1]. For its purposes, Structured Dynamics more precisely defines ontologies as the relationships of the concepts and domains embodied in the underlying things or instances described by the data. Under this approach, ontologies based on RDF become a structural representation of the data relationships in graph form. But, in addition, we also define ontologies to mean the proper description of these concepts, so as to supply the context, synonyms and aliases, and labels useful to human use and understanding.

We therefore put a fairly high threshold of construction and design on our ontologies. These imperatives provide the rationale for this series.

One complementary aspect to our design is the importance to get data in any form or serialization converted to the canonical RDF data model upon which the ontologies define and describe the data structure. Though crucial, this aspect is not discussed further in this series.

Now, of course, when someone (me) has the chutzpah to posit “best practices” it should also be clear as to what end. Ontologies may be used for many things. Others may have as the aim completeness of domain capture, wealth of predicates, reasoning or inference. In our sense, we define “best practices” within our focus of data interoperability and data-driven apps. Your own mileage may vary.

In no particular order and with likely new topics to emerge, here is the current listing of what some of the other parts in this occasional series will contain:

• Intro (concepts)
• ABox – TBox split
• Architecting (modularizing) ontologies into categories (e.g., UI/display of information; domains/instances; admin/internal apps)
• Definition of a standard instance record vocabulary (ABox)
• Role of an instance record vocabulary for universal struct ingest
• Selection of core external ontologies and re-use
• A deeper exploration of the data-driven application
• Initial ontology building and techniques
• Specific UI items suitable to be driven by ontologies (a listing of 20 or so items)
• Techniques for mapping to external ontologies
• Dataset interoperability and the myth that OWL is only useful for real-time reasoning, and
• OWL mapping predicates, importance of class mappings, and OWL 2.

The idea throughout this series is to document best practices as encountered. We certainly do not claim completeness on these matters, but we also assert that good upfront design can deliver many free backend benefits.

If there is a particular topic missing from above that you would like us to discuss, please fire away! In any event, we will be giving you our best thinking on these topics over the coming weeks and how they might be important to you.

First Unveiling of the Bibliographic Knowledge Network, New Product Announcement from SD

Well, it was just about six months ago that Fred Giasson and I announced our new company, Structured Dynamics. After a relatively quiet period and much laboring at the workbench, I will be presenting our new efforts at the 2009 Semantic Technology Conference, June 14th – 18th, at the Fairmont Hotel, in San Jose, California.

I will be speaking on, “BKN: Building Communities through Knowledge, and Knowledge Through Communities,” on Tuesday, June 16, during the 11:45 AM – 12:45 PM last morning session.

BKN — the Bibliographic Knowledge Network — is a major, two-year, NSF-funded project jointly sponsored by the University of California, Berkeley, Harvard University, Stanford University, and the American Institute of Mathematics, with broad private sector and community support [1]. Though initially nucleating around mathematics and statistics, each node in the network is a Web site or dataset distribution hub dedicated to a specific topic or field of knowledge. The project itself is developing a suite of tools and infrastructure based on semantic technologies for professionals, students or researchers to form new communities, and — with a single-click — to share and leverage expertise.

Besides presenting the BKN efforts for this first time, which includes an innovative and open Web services framework for collaboration, I will also be using the occasion of my talk to announce our new semantic Web and linked data RDF framework for content management systems. We’re pretty excited about these advances.

This is my first time at this premier semantic Web event, which has been steadily growing and now exceeds 1000 attendees. The agenda is most impressive; it will be difficult to decide which of the many excellent talks to choose from for each session.

If you will be at the meeting and would like to get together, drop me a note and we can schedule a time. I hope to see you there!