Using Protege (4.0 alpha) as an editor, just to get acquainted with the matter, I tried to develop a little ontology all for myself. The idea behind is to have an ontology that is fit to derive configuration files from. As an example, the config file for a DHCP server will contain the IP numbers of name servers, paths to files on a TFTP server, MAC addresses of network cards of computers, etc. etc. DHCP configuration files are much like one another if we travel from server to server, yet they differ in what specific IP numbers, MAC addresses etc. are mentioned. We could easily generate such a file for our customer by asking them questions like "What is the IP number of your TFTP server?" "What are the MAC addresses and intended IP numbers of all network cards in the same VLAN the DHCP server is in, grouped by subnet and, within these groups, grouped by OS and boot method?" In order to store the answers to these questions, we could create a database.

However, by their nature some of the concepts we try to handle here are more suited to classes as used in object-oriented programming languages than to the rigidity of databases. If the ratio of number of tables to rows per table in a database is any measure of efficiency, the database doesn't give nice figures in this matter, and the effort to create it so that later data might be added, the effort to enforce business logic, and the effort to create and maintain the user interface(s) make this approach seem doomed to futility. Ontologies on the other hand are well suited to an approach that bears likeness to the classes of an object oriented programming language. It can easily handle IP numbers that stem from a list of servers no further specified and IP numbers that come from a list of network cards, handling them as IP numbers in both cases, but still distinguishing between IP numbers that we know as a property of a network card, and IP numbers that we know nothing more of.

An additional advantage of ontologies is that they offer data sharing across multiple repositories. If our customer wants to expand upon our knowlegde base, they are free to do so, and we can even reimport their knowlegde base back into our own, possibly designating it as read-only (see managing imports in protege-owl and also SeparatingClassesAndInstances).

The above links were reached from the Protege WikiHomePage, which is a useful source of information, as is the W3C page on Semantic Web Best Practices and Deployment Working Group. A nice graphical representation of the complexity of some sematic web tools and technologies is the Naive OWL Fragments Map (scroll to bottom of page).

The first issue I ran into is that of user-defined types. The list of available types in OWL is not as rich as that of most RDBs, and certainly not as easily extensible as object oriented programming languages. Where in my PostgreSQL databases I can define a column as being of datatype MAC-address or IP number (be it IPv4 or IPv6), I cannot do so in an OWL ontology. There is an effort to expand and extend the available data types in user-defined datatypes in protege, but it is of limited scale and it uses annotation properties of RDF, which are not visited by the reasoner, which makes the extended data types tag along instead of becoming part of the system. Right now, intricate data types cannot be created in an ontology (just as the cannot be in databases), and a mapping from interface data types to ontology data types is still necessary, as is the implementation of some business logic and data restrictions in that interface. We cannot define something as an IP number, we must store it as a simple string, use it as a string where we can, and when we need to do IP number arithmetic, we must convert it to an actual IP number in our interface. But as I discovered, we may not want these intricate data types anyway...

Another matter is that of unique identifiers. Protege can designate a property of a class as “functional”, which means that two instances with equal values in this property are inferred to represent the same instance. Whether this can be used in the same fashion as “primary key”s in databases needs some more reading and thought on my part. And then there are multi-column primary keys in databases, which allegedly are modeled with “Combined Inverse Functional Properties” in OWL. Haven't found a good source of information for this yet.

One more thing that is highly desirable to a systems administrator is knowing what information is present in what configuration files. As an example: if the IP number of our TFTP server changes, the DHCP configuration file will have to reflect this change. This might seem obvious, but often it isn't trivial to figure out all the places where a single change instantiates. So we would like to have a system that doesn't only generate configuration files, but also `knows' what information it needs to generate them. ^[15] If we are to pull this off, we might have to resort to an OWL full ontology, which cannot be handled by most reasoners, and which cannot be guaranteed to be handled by any reasoner in finite time. Or we can use one of the tricks described in the W3C draft Representing Classes As Property Values on the Semantic Web. In any case, we can reason about classes as values, or we can reason about classes, but we cannot reason directly about the values of properties, and current reasoners cannot reason about instances either. So we probably shouldn't care much about whether we can do AND operations on IP numbers here. That is to be done in the interface.