hypothesis :
1. API infomation is data.
2. By describing an API, we are talking about the interface to something
3. The difference betweeen a model and an API is that a model does not have to present an usable interface
4. The linker presents a set of functions and types to use

rpm2html : a generator of Web pages for RPM packages rpm2html automatically generates Web pages describing a set of RPM packages.

The goals of rpm2html are also to identify the dependencies between various packages and to find the package(s) providing the resources needed to install a given package. Every package is analyzed to retrieve its dependencies and the resources it offers. These relationships are expressed using hyperlinks in the generated pages. Finding the package providing the resource you need is just a matter of a few clicks!

rpmfind : the rpm2html client tool Basically, rpmfind is a program that will find RPM files on rufus for you.

For example, rpmfind gimp will tell you what packages are needed to install Gimp on your machine, where to find them, and how much space it will take on your hard drive (so you can also estimate the download time), and can fetch the required files for you.

Rpmfind can also be used to query the RPM database for existing packages using a keyword or a regular expression.

Rpm2Html: RDF schema for RPM (and others) binary packages The work done on rpm2html, i.e. indexing a large amount
of RPM packages,

http://rufus.w3.org/linux/rpm2html/
http://rufus.w3.org/linux/RPM/

make me believe that there is a real
need for a mechanism allowing easy propagation of the
metadata associated to RPM packages. The goal is to provide
a simple mechanism to export the important information
about RPM packages, without carrying on the full data.

The W3C has issued the RDF draft which in my opnion
suit perfectly the purpose required, I expect that soon
standard browser will be able to parse and display metadata
expressed in RDF format:

http://www.w3.org/Metadata/

I started trying to express the informations contained
in an RPM and needed by rpm2html export the RPM metatdata.

Metadata at W3C Metadata is machine understandable information for the web. The W3C Metadata Activity addressed the combined needs of several groups for a common framework to express assertions about information on the Web, and was superceded by the W3C Semantic Web Activity.

Redfoot.net What is Redfoot?

Redfoot is an extensible RDF server written in Python for building a Semantic Web of P2P nodes. It is being developed by Daniel Krech and James Tauber.
What does Redfoot Include?

* Console Interface
* Rednodes for forming P2P network
* HTTP Server Integration (Currently Medusa, Someday Zope)
* Schema Driven RDF Editor (Web Based)

Primer - Getting into the semantic web and RDF using N3 Primer: Getting into RDF & Semantic Web using N3

The world of the semantic web, as based on RDF, is really simple at the base. This article shows you how to get started. It uses a simplified teaching language -- Notation 3 or N3 -- which is basically equivalent to RDF in its XML syntax, but easier to scribble when getting started.

ITCSL: DAMLJessKB This software is intended to facilitate reading DAML files, interpreting the information as per the DAML language, and allowing the user to query on that information. In this software we leverage the existing RDF API (SiRPAC) to read in the DAML file as a collection of RDF triples. We use Jess (Java Expert System Shell) as a forward chaining production system which carries out the rules of the DAML language. The core Jess language is compatible with CLIPS and this work might be portable to that system. A similar approach is taken by DAML API, they also hook RDF API into Jess. However the bridge they use between the two is a little different and at the moment less complete in at least the publicly available version. Also, the SWI Prolog distribution includes a package to parse RDF and assert as Prolog facts. It should be possible to create a series of Prolog rules similar to the Jess rules used here and leverage that package to create a similar unit for Prolog.

NyktOP Project - Source Languages schema
(only in .pre; implicite in other generators) used as a form of directories to give a better overview of the different classes. Has its roots in Smalltalk categories. Used in C generator to make smaller source dirs.(In MOOSE they can be connected and thus U can decide) to generate certain components)basetype / simpletype
(not in awkinput) Used to define another type for non-structured attributes. Basetypes should be builtin to the generators (Boolean, String), Simpletypes user defined.enumerator
(not in awkinput) Used to define an enumeration type (relevant mainly for C , but very usable also in TCL)foreignclass
(only in .pre) Used to define a class, that must not be generated - e.g. from an external class library used as a type for attributes.record
(only in .pre) very similar to class, but can't define connections; used as a type for structured attributes.array / dynarray
(only in .pre) very similar to record, except that it contains an additional array functionality: U can access an indexed value.class
the most relevant structure for the generators. Thus we show a list of its most common subcomponents:

parent / parents
name(s) of the supertype(s) (multiple only in .pre-ul)schema
name of the schema, this class resides in.attribute
(slottype) define an attribute.reference
(slottype) define an single-sided reference (no support on target side needed).connection
(slottype) define an double-sided connection (the partner/target-object needs to support a responding slot).method
(slottype, only in .pre) define a new method in the class (used only for the C generator).
module
(only in .pre) define a module; may e.g. be used to include components, that do not fit into NyktOP class hierarchies, like old (ansi) C libraries.