Unfortunately, these approaches don't work very well for applications that have lots of windows. Terminal programs, for example, may have dozens of windows, each presenting a different shell and/or application context. Mac OS X doesn't let me hide some of an app's windows, so that's out. The Dock and WindowShade are awkward ways to manage dozens of windows; simply dismissing and retrieving a set of several windows becomes quite a hassle.]]> Fortunately, it turns out that there is a (relatively) simple workaround. By using multiple copies of an app (e.g., Terminal), I can hide and display each copy's windows separately. I currently have four copies of Terminal available. One is used for generic tasks, two are used for specific projects, and one is idle.

The arrangement is working well. Any new Terminal window I create (via cmd-N) becomes part of the current copy's set. I even found a way to let a script know which Terminal it's running under. Finally, although it might be nice to be able to migrate windows between sets, this has not been a serious deficiency in practice.

HOWTO

Here's a basic walkthrough of the procedure. Feel free to season to taste; it's your machine, after all! However, if you're a bit paranoid, you may want to quit the relevant copies of Terminal before performing these steps.

• Copy the preference file and the Terminal app.

  Using the Finder, go to ~/Library/Preferences and copy com.apple.Terminal.plist to com.apple.Terminal_2.plist. Then, go to /Applications/Utilities and copy Terminal.app to Terminal_2.app.

• Link up the app to the preference file.

  Control-click on Terminal_2.app and select "Show Package Contents". In the Contents folder, double-click on the Info.plist file. In the resulting Property List Editor, change CFBundleIdentifier from com.apple.Terminal to com.apple.Terminal_2. Save and Quit to make the changes permanent.

• Trim the foreign language support files (optional).

  In the Resources folder, remove any superfluous *.lproj files. This can reduce the copy's disk storage by more than 60%.

You can now start up and play with the copied app. Some customization is also a reasonable idea at this point. The following sections explain how to change the windows' titles, the app's name in the Menu Bar, and the value of the TERM_PROGRAM environment variable. The techniques get increasingly scary as we go along; feel free to bail out at any time...

Window Titles

It's easy to change the "Title" information that gets used on each window. Pull down Terminal > Window Setting from the Menu Bar, then select the "Window" category. Change the "Title" fill-in to "TS2" (Terminal Set 2). Note that each copy of the app has its own preferences, window settings, etc. So, if you want to make a global change, you'll have to adjust each copy.

Menu Bar

If you have Xcode installed, you can change the Menu Bar to say "Terminal_2" (or whatever). Navigate to the Contents/Resources/English.lproj folder and double-click on Terminal.nib. After Interface Builder has started up, double-click on the "Terminal" string in "Terminal.nib (English) - MainMenu" and fill in the desired value (e.g., Terminal_2). Save and Quit.

Now, double-click on InfoPlist.strings. When a text editor window appears, change the value of CFBundleName to the same text string. Save and Quit. When you next start up Terminal_2, the Menu Bar will read correctly.

Shell Support

It's handy for shell scripts to be able to find out which terminal set they are in. This can be used, for example, in dynamically setting window titles or command-line prompts. My current solution, which is a bit scary, is to edit the executable binary for the application. If you're comfortable with this idea, read on...

This hack is based on the fact that Terminal sets up a pair of environment variables for its sessions. One of these, TERM_PROGRAM, is normally set to Apple_Terminal. By editing Terminal's executable, we can change this value to a different text string.

Navigate to the Contents/MacOS folder. Using a binary-capable text editor (e.g., BBEdit), open the original executable. Search for the text string Apple_Terminal. In my executable, it is preceded by TERM_PROGRAM and followed by the string TERM_PROGRAM_VERSION, but Your Mileage May Vary.

Select the part of the string you wish to change and replace it with an equal number of characters. (I use Apple_Term_TS2 for Terminal_2.) Save and Quit. When you next start up the app, this string will be available in TERM_PROGRAM.

Final Comments

Although this exercise used Terminal as its target app, the same sorts of changes could be made to any app. By (a) breaking apps up into phalanxes of files and (b) giving us the tools to edit these files, Apple has given its users quite a bit of freedom. Not as much as an Open Source application would provide, to be sure, but still very handy on occasion.

Although he bears no blame for any of my ideas or mistakes, David Hill was splendidly helpful in my effort to change the app's title in the Menu Bar. Having worked closely with David in co-authoring the Mac OS X Technology Guide to Spotlight for SpiderWorks, I expected no less. Nonetheless, it's nice to have one's positive expectations confirmed.]]> tag:www.cfcl.com,2006:/~rdm/weblog//3.1053 2006-04-17T22:13:21Z 2007-01-09T15:25:07Z

  ==Current Standings==

  {{sports_team_standings:Wombats | current}}

I subscribe to a number of mailing lists that discuss knowledge engineering and related topics. I've also skimmed through many related books and papers. The main thing that has become clear to me, from all of this study, is that knowledge engineering is a complex, subtle, and (as yet) ill-defined discipline.

If the experts can't agree on how to approach the creation of ontologies, or even how to define the relevant terminology, can an application programmer such as myself hope to do anything useful? Well, Larry Wall says that hubris, laziness, and impatience are the three great virtues of programmers. If I can harness the latter two properly, I may be able to justify the first...

Getting Started

A full Ontiki system will require the integration of a variety of technologies, but I have to start somewhere. So, following the techie commandment to "eat your own dog food", I decided to use a mechanically-augmented wiki to develop and display a naive ontology for the Unix operating system. See MBD: Case Study (Unix) for background information, etc.

The underlying wiki technology is provided by MediaWiki, a PHP-based wiki that is used by Wikipedia and many other substantial wikis. MediaWiki is convenient, portable, full-featured, and robust; it also has active user and developer communities.

Wiki Access

Although I am intrigued by the notion of using DBMS tables for inter-application communication, adding a page to MediaWiki involves updating about a dozen tables. This requires a much closer relationship with MediaWiki's logic than I have any interest in having.

Fortunately, others have blazed a trail that I can follow. Pywikipedia is a Python-based "bot" (robot) framework for HTTP client scripts. Although it was originally developed for accessing Wikipedia, it can access any MediaWiki-based wiki. Using this framework, I can get and put the text of wiki pages, upload images, etc.

Data Storage

Of course, this begs the question of where to store the information that is used to create the wiki pages. I hope to migrate, in time, to an RDBMS, a knowledge base framework such as Protégé, and/or a knowledge representation and reasoning system such as PowerLoom. However, I'm still not sure which way to jump.

So, for the moment, I'm using an informal approach: a directory tree of several dozen hand-edited YAML files. Each directory corresponds to a class; a YAML file in each directory defines the class, lists its relationships, etc. The YAML files are readable, self-documenting, and extremely flexible in structure.

Editing an extensive hierarchy of files is quite awkward using command-line tools (e.g., vi). Fortunately, my explorations into Ruby on Rails introduced me to the excellent TextMate editor. Using its Project drawer, I can view the directory hierarchy, disclose and hide sub-trees, and jump into any desired file at the click of a mouse.

Every so often, I use a Perl script to concatenate the files, process the definitions, and load the web pages. The script looks for problems (e.g., missing definitions) and generates assorted cross-references, indexes, etc. This run takes about five seconds per page, however, so I don't do it all that often.

The Ontology

As mentioned above, this is a "naive" ontology. I don't expect it to support much in the way of deduction; it simply has to provide a way to organize classes and instances of entities and relationships. At this point, I'm only working with "abstract classes"; once I get these sketched in, I can look at lower levels (e.g., "concrete classes", "instances").

For simplicity and flexibility, I treat everything as entities. This includes not only conventional entities (e.g., file node), but also attributes (e.g., is interpreted) and relationships (e.g., may include). Attributes may have zero or one value; relationships may have two or more roles.

The top level of the ontology (thing) is currently a bit of a muddle. The reason for this is that I'm mostly just entering concepts at this point. I suspect that a bit more order will emerge as I actually try to use these classes for something!

Anyway, feel free to take a look. The Abstract Class (AC) Index is structured (roughly :-) as an "is a" tree (i.e., taxonomy). However, because it allows multiple inheritance, it's really a directed acyclic graph (DAG).

If you are interested in helping me fill in the ontology, and have some part of Unix which you are knowledgeable about, please contact me. There are some substantial parts of the ontology (e.g., networking) that I've simply punted on, for lack of knowledge and/or time.

What's Next

Now that I can generate and upload wiki pages, I get to choose between enhancing their content and improving their appearance and usability. In all likelihood, I'll work on all of these areas. Comments, suggestions, and help are all welcome...

Image-mapped diagrams work well for context and navigation, but they aren't supported by MediaWiki "out of the box". So, I'm looking into ways to provide this capability. For examples of how I've used these diagrams in the past, see MBD: Case Study (FSW).

Getlets extend InterWiki notation, allowing wiki pages to draw upon arbitrary dynamic content. This could allow users to create their own dynamic reports, simply by editing a wiki page and asking for the right content.

PowerLoom is a well-regarded knowledge representation and reasoning system. I have downloaded a copy and am trying to get up to speed on it, as well as evaluate its suitability as a back-end server for Ontiki.

In short, there is no shortage of interesting research directions. Stay tuned; I'll let you know what I find out...

Technorati Tags: knowledge representation, MediaWiki, Model-based Documentation, Ontiki, ontology, PowerLoom, Pywikipedia, semantic wiki, TextMate, Unix, wiki]]> tag:www.cfcl.com,2006:/~rdm/weblog//3.1010 2006-03-13T01:21:28Z 2006-04-13T05:22:09Z

  # Describe each _query_, specifying any needed SQL statements
  # and/or executable scripts (e.g., output filters).

  Queries:
    _query_:
      sql:          |
        SELECT  foo
        FROM    Bar;
      script:       _script_

  # Describe each _report_, specifying each included _query_
  # and any surrounding text.

  Reports:
    _report_:
      subject:      'This is the subject line.'
      title:        'This is the title text.'
      description:  >
        This is a short (wrapped) description.
      content:
        - b:        |
            This is some block-formatted text.
        - t:        >
            This is some normal (wrapped) text.
        - q:        _query_

  # Describe each _user_, specifying each desired _report_
  # and when it should be delivered.

  Users:
    _user_:
      address:      'rdm@cfcl.com'
      full_name:    'Rich Morin'
      reports:
        - name:     _report_
          when:     'Mon Wed Fri'

  $r->{Queries}{$query }{sql}             # SQL command for $query

  $r->{Reports}{$report}{content}[0]{b}   # some block-formatted text
  $r->{Reports}{$report}{content}[2]{q}   # the name of a _query_

  $r->{Users  }{reports}[0]{name}         # the name of a _report_
  $r->{Users  }{reports}[0]{when}         # a list (string, really) of days

  #!/usr/bin/env php

  <? # Loop over desired intervals.

    $i_hash  = array('today'     => 'NOW()',
                     'yesterday' => 'NOW() - INTERVAL 1 DAY',
                     'last_week' => 'NOW() - INTERVAL 7 DAY',
                    );

    $t_list  = array('foo', 'bar');

    foreach ($i_hash as $i_key => $i_val) {

      foreach ($t_list as $t_item) {
  ?>
      <?= $t_item ?>_entries_for_<?= $i_key ?>:
          sql:            |
            SELECT    COUNT(*)
            FROM      Events
            WHERE     date       =  <?= "$i_val\n"  ?>
            AND       type       =  '<?= "$t_item\n" ?>';
  <? } ?>

      foo_entries_for_today:
          sql:            |
            SELECT    COUNT(*)
            FROM      Events
            WHERE     date       =  NOW()
            AND       type       =  'foo';
      foo_entries_for_yesterday:
      ...

    ksort($i_hash);

#!/usr/bin/env perl
#
# fdf - first digit frequency (in file sizes)
#
#  Usage: sudo fdf
#
# Benford's Law predicts the probability of 'd' occurring as the first
# digit of a number to be log10(1 + 1/d), assuming that the number has
# at least four digits.  For details, see:
#
#  "Following Benford's Law, or Looking Out for No. 1"
#  http://www.rexswain.com/benford.html
#
# Written by Rich Morin, rdm@cfcl.com

use strict;
use warnings;

use File::Find;
use POSIX qw(log10);

our (@cnt, $cnt);

{
  my ($d, $data, $hist, $path, $pred);

  $path = '/';

  finddepth(\&wanted, $path);

  print "cnt: $cnt\n\n";
  print "d  pred.  data           1         2         3         4\n";
  print "                123456789 123456789 123456789 123456789\n";

  foreach $d (1 .. 9) {

    $pred = 100 * log10(1 + 1.0/$d);
    $data = (100.0 * $cnt[$d]) / $cnt;
    $hist = '*' x int($data + 0.5);

    printf("%d (%4.1f): %4.1f  %s\n",
           $d, $pred, $data, $hist);
} }


sub wanted {

  my $s = -s $_;

  if (-f $_) {
    if ($s > 999) {
      $cnt++;
      $cnt[ substr($s, 0, 1) ]++;
} } }

cnt: 766281

d  pred.  data           1         2         3         4
                123456789 123456789 123456789 123456789
1 (30.1): 32.1  ********************************
2 (17.6): 19.7  ********************
3 (12.5): 13.4  *************
4 ( 9.7):  9.4  *********
5 ( 7.9):  7.3  *******
6 ( 6.7):  6.0  ******
7 ( 5.8):  4.8  *****
8 ( 5.1):  4.1  ****
9 ( 4.6):  3.1  ***

  $WP = 'http://en.wikipedia.org/wiki';

  # ah - generate an "a href" link 
  #
  function ah($url, $text) {

    print "<a href='$url'\n"
        . "   target='_blank'\n" 
        . "  >$text<a>" 
        ;
  }

   About half of the pages are generated by 
   <?= ah("$WP/Doxygen",                 'Doxygen'); ?>, a well-known
   <?= ah("$WP/Documentation_generator", 'documentation generator'); ?>;
   the rest are generated by custom Perl scripts.

   About half of the pages are generated by 
   <a href='http://en.wikipedia.org/wiki/Doxygen'
      target='_blank'
     >Doxygen<a>, a well-known
   <a href='http://en.wikipedia.org/wiki/Documentation_generator'
      target='_blank'
     >documentation generator<a>;
   the rest are generated by custom Perl scripts.

  <? $T1 = 'Some Really Enormous URL...'; ?>

  <p>
    <?= ah($T1, 'yada yada...'); ?>

    <?= ah('http://www.clues_are_optional.xyz'
         . '?tag1=1234567890123456789012345678901234567890'
         . '&tag2=1234567890123456789012345678901234567890',
           'Clues are optional...'); ?>

  <? include 'mbd_defines.php';
     do_page('Case Study');
  ?>
    ...
    <?= sect_head('Design Goals'); ?>
    ...
    <?= sect_head('Implementation'); ?>
    ...
    <?= next_link('mbd_advice.php', 'Advice'); ?>
  <? page_footer(); ?>

As an ontology-aware wiki, Ontiki would allow pages to represent classes and instances of entities and relationships. The hope is that it could combine a wiki's convenience and freedom with the strengths of ontology-based systems, allowing a graceful merging of human-edited and mechanically generated content.

Technorati Tags: knowledge representation, model-based documentation, ontiki, ontology, semantic wiki, wiki

An ontology, in computer science parlance, is a set of statements (primarily, definitions) concerning a domain of discourse. Thus, an ontology defines the things we are talking about and makes assertions about their attributes and relationships. For example, the statement "control files may be read by processes" might be found in an ontology for computer software.

Ontologies are very popular these days. They are used extensively in knowledge engineering and form a critical part of the proposed semantic web. Unfortunately, I haven't found any ontology-based tools that strike me as being as flexible and easy to use as the typical wiki.

Wikis are extremely easy to edit. Links can be created by the simple act of typing in a CamelCase word. If a page doesn't already exist, the act of clicking on its link will create one. Simplified markup_languages are also available, easing the process of page creation.

The web's basic architecture reduces the apparent complexity of web site (and thus wiki) generation. Although collections of pages and links form a graph-based data structure, few users think about this fact. Looking at any given page, the user sees only content and links; the global structure can be (and usually is) ignored.

In Ontiki, a similar simplification should apply. Each page will only describe a given class or instance of an entity or relationship. So, although the user will get the benefits of a page's relationships (e.g., displays of deduced information, clickable diagrams for context and navigation), s/he will not need to keep the entire ontology in mind.

By allowing wiki pages to have precisely specified attributes and relationships, Ontiki should be able to provide improved context and navigation, generate and display deduced content, etc. At least, I think it's worth a try!

Web Limitations

Web links (e.g., <A HREF="...">...</A>) have limitations that greatly hamper automated analysis. By augmenting a wiki with better structure and more metadata, we can "get a better grip" on the relationships involved.

Because a web link only goes to a given page, the entire graph must be traversed in order to find backlinks (links that come from other pages). For search engines such as Google, this can be a massive problem, because the "graph" in question is the entire web.

Most wikis do not bother to track backlink information. Even fewer can display clickable context diagrams, showing a page's "local neighborhood". Pimki (an experimental "Personal Information Management" wiki) does both, but it is a conspicuous exception.

Even Pimki, however, is constrained by the limitations of HTML links. Although a link can have many attributes, most only contain the URL for the target page and the text content to be highlighted and displayed. Nothing, in any case, indicates which links are of what "type".

Without typed links (e.g., Is_A, Has_A, Used_By), Pimki has very little information to work with. It cannot, for example, filter by link type or assess the "strength" of given links, much less make deductions (e.g., inherited characteristics) based on link types.

Ontology Awareness

By letting users add ontological information, Ontiki would overcome these limitations, as well as provide a convenient framework for mechanical generation and/or augmentation of pages. This should work particularly well for documenting the details of highly-structured systems such as collections of computer software.

In an Ontiki web about a Unixish operating system, pages might represent classes such as File or Control_File, instances such as /etc/passwd, etc. Relationships such as Read_By and Written_By could be used to connect entity pages in well-defined ways.

Because relationships (and the roles within them) would be defined in terms of class definitions, instances would only be allowed to take on "legal" roles. As a Control_File, /etc/passwd would not be allowed to occupy the Process role of a Read_By relationship.

Given a suitable ontology, mechanized harvesting could be used to populate many instance pages with attribute and relationship information. For example, a scan of the Unix man pages could fill in details on related documentation, files, etc.

Human participants, meanwhile, could make arbitrary links and post comments or ask questions about any portion of any page. By specifying interest in particular topics (e.g., Control_File), they could also receive notification of changes, questions, etc.

The Bad News

If a topic is highly structured and well understood, defining an ontology for it may seem rather trivial. Even so, there are many opportunities for confusion. William Kent's short book, Data and Reality, is a very readable introduction to these sorts of problems.

As topics get fuzzier, categorization can become difficult or even impossible. George Lakoff's book, Women, Fire, and Dangerous Things is a fascinating introduction to category theory, drawing on disciplines such as anthropology, cognitive science, linguistics, and philosophy.

John Sowa's slide sets, The Challenge of Knowledge Soup and Representing Knowledge Soup In Language and Logic, are entertaining introductions to knowledge engineering. His introductory textbook, Knowledge Representation, is more daunting, but very worthwhile.

Finally, Clay Shirky's essay, Ontology is Overrated, is an amusing and informative (if quite informal) overview and critique of ontology and the semantic web.

The Good News

If Ontiki were intended as a full-scale expert system, the difficulties noted above would be far more worrisome. However, Ontiki is more like a "wiki on steroids", keeping track of ontological assertions and (occasionally) making trivial deductions. So, we can live with a bit of error and imprecision.

In creating or editing Ontiki pages, users may assert things (e.g., attributes or relationships) that aren't useful or even "true". However, other users are perfectly free to ignore these assertions. In short, relax...

Implementation

Even if I were in a position to create such a system from scratch, it would be silly to do so. By basing Ontiki on technologies with Open Source implementations, I can take advantage of existing code, interfaces, user communities, etc.

Ontiki's "front end" will probably be based on a Rails-based wiki, such as Instiki or Pimki. This should give me a nice model-view-controller architecture for my base wiki, allowing great flexibility in adding new functionality.

I also need to decide on a knowledge representation scheme for Ontiki's "back end". For obvious reasons, I'd like this to allow interoperability with other semantic web and knowledge representation projects. I'd also like to leverage existing work in related areas. I've found a number of promising technologies, including:

• Conceptual Graphs (CG)

• Object Role Modeling (ORM)

• Resource Description Framework (RDF)

• Topic Maps (TM)

• Unified Modeling Language (UML) class diagrams

CG comes from the expert systems side of the artificial intelligence (AI) community. ORM was created as a design technique for database management systems. RDF and TM, aimed at indexing documents, are emerging standards for the semantic web. UML was created as a "standard" set of diagramming notations for software design.

Separated at Birth?

Despite their differing origins, there are strong similarities between these technologies. For example, CG, ORM, TM, and UML all provide variations on entity-relationship diagrams (ERDs). So, it's not inconceivable that any or all of them could be used as differing "views" of a given set of knowledge.

The advantage of this, from my perspective, is that it could allow me to take advantage of the differing strengths of given representations. CG, for example, is based on a form of predicate calculus known as first-order logic (FOL). In fact, this allows CG to be used as one of the syntactic variants of Common Logic (CL), a proposed standard for knowledge interchange.

ORM's notation is a bit different from CG's, but it shares many common aspects. For example, both systems describe collections of entities, playing specified roles in multi-way (i.e., N-ary) relationships. The big difference, with ORM, is that ancillary notations can be added to help in the definition of a supporting database schema.

RDF is, comparatively speaking, a very low-level representation (based on subject / predicate / object "triples"): sort of an "assembly language" for knowledge representation. Nonetheless, RDF is gaining adherents (and supporting software) at a rapid rate, so it's clearly a technology to watch.

It's not inconceivable that Ontiki could use (or borrow from) multiple notations and representation schemes, taking advantage of their respective strengths. Unfortunately, each of these technologies has its own supporting software, user communities, etc. What to do; what to do...

Protégé, Amine, or ???

My current thought is to use Protégé as the back end. Initially created as an ontology editor, Protégé is now a substantial and very extensible knowledge-base framework. It can define and use fairly arbitrary knowledge bases, either interactively or by means of a web services interface.

Using Protégé as Ontiki's knowledge base would let me take advantage of a powerful system and dozens of "plug-ins". New plug-ins (e.g., for CG or ORM) are also a possibility. Thus, it might be possible for Protégé to support assorted diagramming notations as input and editing modes.

Initially, Protégé can serve as an interactive tool for defining and experimenting with ontologies. Over time, some of this activity could migrate to the wiki, though it would probably be limited to "administrative" users.

Better yet, Protégé isn't the only game in town. The Amine Platform, for example, offers a roughly equivalent set of capabilities. (Please feel free to direct me to other possibilities!)

Back to Reality

Although I have prototyped some relevant technology, Ontiki is entirely vaporware at this point. Thus, even the design comments are very speculative (after all, I'm still looking for interesting technologies to "borrow"). Stay tuned, however; I might eventually produce something...

Technorati Tags: knowledge representation, Model-based Documentation, Ontiki, ontology, semantic wiki, wiki]]> tag:www.cfcl.com,2005:/~rdm/weblog//3.681 2005-02-12T20:00:24Z 2006-01-02T07:55:44Z