Slots vs. Members

(OK, now, this is an article about data structure design, not some euphemistic battle of some genders.)

(Are open-Internet confessions of ignorance really a good idea? I only post such a thing in the hopes that someone may find it useful as a bridge to some subject they hadn’t though about before. In this case, if you’re a ‘programmer’, maybe you haven’t though much about ‘knowledge bases’ before.)

In messing around with Protégé, I’m learning about the knowledge-base concept of slots versus the programming concept of members. Please keep in mind in that I still haven’t bothered to even read the Protégé project’s no-doubt-excellent tutorial on ontology design, nor any books on knowledge-bases, -capture, -management, etc., though I really will some day. Anyway, for the purposes of this article I’m just a software developer who happens to have stumbled upon an interesting tool.

Many popular programming languages (C, Java, Python, etc.) have a simple mechanism by which you can create your own application-specific types. You create classes/structs that have members, like so*:

struct HairInfo
{
float Length;
float CurlFactor;
...
}

If you had another struct

struct String
{
float Length;
char *Str;
...
}

the two ‘Length’ members would not conflict with one another because they’re in different namespaces. One would tend not to think of them as being related in any very deep manner. In fact, if you wanted to represent the fact that the members _were_ deeply related, you’d probably create a new type to use instead of ‘float’, and use that type for both members.

In the Protégé world, trying to create two ‘members’ with the same name _will_ lead to a conflict. Cuz you’re not creating members, you’re creating slots, and those all live in the same namespace. Which seems weird, coming from classes’n’members background. Members are pieces of an object; slots are descriptions attached to an object.

Protégé does it this way, I’m guessing (because I haven’t actually read), to add an additional dimension of semantic richness to knowledge structures. This concept is also found in another topic I don’t know enough about, RDF/Semantic Web, where there’s a (universal) namespace of predicates. The point is that, for example, you may be able to apply the predicate ‘creator’ to a book, a web page, a magazine, a tree, etc., and that in a connected world, you can search the world for, say, “creator=’Steven Ourada'” and find all the things someone claims I created, without having to know beforehand to what sorts of things that predicate might be attached.

So a system like Protégé shares predicates, or descriptors, or slots, or whatever, rather than types. That’s interesting. That’s my only point.

* A long time ago, I shared space (in a rented GE trailer. Did you know GE rents trailers for temporary office space? I did not know that before I worked in one.) at Engineering Animation Inc. (EAI) (I wish the Wayback Machine kept images. How useful is this?) with the Barbie Magic Hairstyler team. One of the things I remember hearing people talk about was the HairInfo struct. This is by far not the oddest thing I ever heard in that trailer, but it still sticks out.

In case you want to know more about the making of Barbie Magic Hairstyler, contact Adrian Sannier. Yeah, I didn’t think so.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.