Metadata for Fork Sake

Once in a while, I get excited and frustrated about the state of metadata - particularly in file systems. Previously, I've written about rumors of OS X doing metadata better and the wonders of BeOS. A resource fork is something that Macs have had for ages, although it has appeared in other systems before and since:

The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the Alto in Smalltalk-76...Although the Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support, called an alternate data stream, has never been used extensively...Early versions of the BeOS implemented a database within the filesystem...Though not strictly a resource fork, AmigaOS stores meta data in files known as .info files...NeXT operating systems NeXTSTEP and OPENSTEP, and its successor, Mac OS X, and other systems like RISC OS implemented another solution. Under these systems the resources are left in an original format, for instance, pictures are included as complete TIFF files instead of being encoded into some sort of container.

This links to the Grand Unified Model 1 and Grand Unified Model 2 which are also good for a few quotes:

Almost every piece of data in the Macintosh ended up being touched by the Grand Unified Model. Even transient data, data being cut and pasted within and between applications, did not escape. The Scrap Manager labeled each piece of data on the clipboard with a resource type. In another Mac innovation, multiple pieces of data, each of a different type, could be stored on the clipboard simultaneously, so that applications could have a choice of representation of the same data (for example, storing both plain and styled text). And since this data could easily be stored on disk in a resource file, we were able to provide cutting and pasting of relatively large chunks of data by writing a temporary file called the Clipboard.

Since resource objects were typed, indicating their internal data format, and had ID's or names, it seemed that files should be able to be typed in the same way. There should be no difference between the formats of an independent TEXT file, stored as a standalone file, and a TEXT resource, stored with other objects in a resource file. So I decided we should give files the same four-byte type as resources, known as the type code. Of course, the user should not have to know anything about the file's type; that was the computer's job. So Larry Kenyon made space in the directory entry for each file for the type code, and the Mac would maintain the name as a completely independent piece of information.

Getting up to Speed With OWL 1.1

Bijan's "Two Interesting Quotes" really got me started on understanding the new features of OWL 1.1. The addition of the RBox (to ABox and TBox), using SROIQ instead of SHOIN, is the obvious one.

The second interesting quote was from, "Describing chemical functional groups in OWL-DL for the classification of chemical compounds" which gives some clear examples using the new features of OWL 1.1 including qualified cardinality, negation and property chains. The first two are analogous to: chemical has two bonds and chemical has exactly one bond.

Property chains are another interesting feature which is highlighted in the above paper, in "The OBO to OWL mapping, GO to OWL 1.1!" and in the first paper Bijan spoke about. In one way this is a bit disappointing because the OBO work replicates what we been doing in the BioMANTA project (I hate duplication in all its forms) - we based it on the Protégé plugin. Our relationships are quite simple, mainly is-a, so OWL DL was enough. We hadn't yet encountered some of the problems such as reflexive and anti-symmetric relationships. It also links to a web page mapping OBO to OWL 1.1 and OWL DL semantics.

As noted in "Igniting the OWL 1.1 Touch Paper: The OWL API" the addition of an object model along with the OWL 1.1 specification makes it obvious what an OWL 1.1 API should look like. I haven't yet used OWL API much, except looking at how it integrates with Pellet and how closely it matched the OWL specification. The use of axioms made the addition of RBox a bit easier to understand (or misunderstand if I've got it wrong). Hopefully, punning will be made clear to me eventually too (I've been too stupid to understand it just based on the explanations and too lazy to look into it). Pellet 1.5 also introduces incremental inferencing which is hopefully as good as it sounds.

The other papers that were of interest: "Representing Phenotypes in OWL" (again making use of qualified cardinality) and "A survey of requirements for automated reasoning services for bio-ontologies in OWL".

And just to round off, I found a very good paper, "Towards a Quantitative, Platform-Independent Analysis of Knowledge Systems", about all the mistakes that can be made during modeling (errors, assumptions, etc.) and other types of failures such as language (under or over expressive), management, learning, reasoning, querying, and others.

And I know I'll need to come back to this, which lists the fragments of OWL 1.1 that can be used to keep things computable in polynomial time.

Data and Metadata

Hysteresis, History and empty metadata fields "Hysteresis occurs whenever the effect that accompanies some cause is delayed for some reason. The term is most often associated with processes in the physical world. The movement of interest rates, the growth of insect populations, the rise and fall of magnetic fields, that sort of thing."

"There is a hysteresis-based relationship between content and non-trivial metadata about the content."

"Writers write and categorizers categorize. There is an unavoidable delay between the two activities. The writers and the categorizers can be the same people but the activities are very different and cannot be done at the same time. Build this hysteresis into your workflows rather than fight against it. The alternative is blank or dummy metadata fields."

Anti-metadata Google

Dear Mr. Bosworth "I can't believe that a smart guy like you could advocate Poscasting as a solution to the complexity of the semantic web and all that enterprise, corporate complexity - without a hint of meta-data - anywhere.

How's the work? Inference? Osmosis?

I know that Google is known as an anti-meta-data sort of place - but PLEASE oH LORd - get over that!

This is NOT about the religious wars of RSS 1.0 vs RSS 2.0. I couldn't give a dam about rdf, T B-L or any of that semantic web hooey.

I'd just like to see folks standardize on attributes, properties and meta-data around these new, burgeoning forms of micro-content."