This information is not current. The concepts outlined in this page evolved and were implemented in Amiga Forever 2008. Please refer to the RetroPlatform SDK for additional information.

Introduction

After almost 10 years of development, the Amiga Forever project was referencing more than thousand companies, individuals, software applications and other entities. Increasingly, it was taking more and more time to double-check things to prevent errors and avoid duplications. This is not only because of typos or other errors in our original sources (at times even in official documents, or with search engines showing a higher frequency for a wrong name than for the correct one), but also in large part because the data had never been structured and organized for this type of reference.

For Amiga Forever 2005, different options were considered to start organizing the data. This meant not only building a database of all people and organizations mentioned in documents, audio recordings, videos, etc., as well as Amiga Forever licensors and contributors, but also, for example, the XADML-described games and demos that would be supported by the new launcher. Now, if organizing known data seems possible, if not easy, cataloging, or at least managing identifiers for unknown data, such as all Amiga applications in existence, is more of a challenge. Without a unique identifier, for example, a game front-end listing a title that is available online wouldn't be able to tell whether the same game is installed or not.

From UUIDs and CRC32s to OIDs

The worst-case scenario of the cataloging project was represented by the above-described need to uniquely identify an open-ended number of unknown software titles (e.g. games, demos).

In order to provide a decentralized solution to this collective problem, it was considered to use UUIDs, which were guaranteed to be unique, and which anybody could self-assign to, say, a game that was not yet cataloged. In theory, before assigning a UUID to an application, the cataloging entity would check or otherwise be aware of an existing UUID, and use that if available. In case of duplicate assignments, over time the UUID with the lowest timestamp would "win". CRC32 checksums were proposed as another option. Although not guaranteed to be unique across images (two files may in theory have the same CRC32), CRC32s have the advantage of being "self-assigned". In practice, it emerged that CRC32s already work well as a means of identifying software media, e.g. as used in popular emulation packages. CRC32s are therefore used to identify media files in XADML files, with some additional logic applied to locate such files if necessary.

UUIDs and CRC32s reflect the need to solve a problem in a decentralized manner. Otherwise, uncataloged applications would have had to wait for some central action (e.g. addition to a database) before being supported in the new XADML-based system, which was deemed to be impractical.

The adoption of a common-sense solution to the time-sensitive part (i.e. applications that should not have to wait to be cataloged for identification purposes), gave the cataloging part of the project the possibility to adopt a best-of-both-worlds approach. Because other items that could benefit from cataloging are not time sensitive (there is a long-term benefit, but no real urge to create a single list of known Amiga entities), it is believed that the best approach to organize this data is to manually associate a unique identifier to each entity. This is what has already been done for the entities which fall under the Amiga Forever project. For this purpose, an object identifier (OID) structure as per ITU-T recommendation X.680 and RFC 2252 was defined and used.

Some of the benefits of the OID model include:

• OIDs are backed by existing standards and practice

• Anybody in the world can know with a simple online check what an identifier means, and who manages it

• Responsibility for the management of OID subtrees can be delegated

• Because numbers are used to identify entities, there is no need to manually choose tags, or to rename them if entity names change, etc.

Applied to the Amiga community, we believe that OIDs could be used, for example, to reference companies, people and applications across different websites and the databases behind them. Currently, for example, different sites dedicated to preserving information about Amiga games use different methods to identify game developers, publishers, programmers, artists, titles, etc. If every site had just one URL access point where an OID could be entered, the public (and a site's own maintainers and researchers) could more easily check for information about the same entity. Aggregation front-ends could be created, pointing to information for similar entries in different sites and resources (e.g. information about every name mentioned in every video in the Amiga Forever archives).

Amiga Cataloging Project Object ID Subtrees

The following subtrees have been assigned for use in the RetroPlatform Cataloging Project.

• 1.3.6.1.4.1.23153.1000 RetroPlatform Cataloging Data
• 1.3.6.1.4.1.23153.1000.0 Reserved
• 1.3.6.1.4.1.23153.1000.1 Natural Persons, Legal Entities and Organizations
• 1.3.6.1.4.1.23153.1000.2 Hardware
• 1.3.6.1.4.1.23153.1000.3 Official Publications and Data
• 1.3.6.1.4.1.23153.1000.4 Interim Publications and Data

Subtrees of the above can be assigned, with delegation of the respective administration (e.g. clearly defined Amiga categories such as "games", "demos", "books", "magazines", "video", "audio", etc. could all be subtrees of "publications").

General Recommendations

The use of OIDs brings with it a healthy minimum of formal requirements (which guarantee some "order"), while allowing for a diversity of implementations.

For example, although originally set up to ease maintenance of Amiga Forever, each subtree of the Amiga Cataloging Project could be managed by a different organization. A fundamental requirement for these organizations is to make available the full list of assigned OIDs. This could be via real time online access to a database, or by publishing the entire list as a text file from time to time (which also constitutes a public backup of the data).

Public accessibility and submissions are encouraged. In order to minimize the risk of abuse and contamination, it is suggested to manually approve each submission, or to at least implement a system for automatic email confirmation.

If it is determined that more than one OID has been assigned for the same entity, then the one with the lowest number should be given preference, and steps should be taken to inform the parties that used the other OIDs. Duplicate OIDs issued by mistake should not be reassigned, and should be reserved indefinitely.

OIDs already assigned to one entity are never reassigned, including but not limited to cases of death, liquidation, etc.

Wherever OIDs are used, only full (complete) OIDs should be used (e.g. "1.3.6.1.4.1.23153.1000.1.1", not "1.1" or "1"). Although it costs a few extra bytes, this makes an OID immediately recognizable as such, and helps maintain long-term integrity and order. Also, it makes it possible to combine references with other projects that use OIDs, and for other projects to link to items which are the result of this Amiga-focused effort.

Public Domain

The information associated to each OID includes at least a short item "title", and, if necessary, a minimum of information required to disambiguate it from other items. As part of the Amiga Cataloging Project, this combined set of essential identifying information is placed in the public domain. No copyrights may be claimed over this information, neither individually nor on the entire record or collection set.

Any other content added by third parties to an item (e.g. extended description) may be subject to copyrights or other terms as desired by such contributors.

Natural Persons, Legal Entities and Organizations

This subtree includes all people, companies, and other organizations (e.g. demo groups). It also includes animals (e.g. Jay Miner's dog Mitchy), fictitious characters (e.g. Joe Pillow) and pseudonyms of otherwise unknown entities (e.g. Questionado Mysteriouso).

Every company that has legal entity status per local legislation definitely has its own OID. If a company is simply renamed, the OID does not change, because it remains the same legal entity. Other corporate transformations are usually covered in great detail by local legislation, which specifies whether the legal entity remains the same (e.g. for issues of responsibility, etc.) or not. Care should also be taken when cataloging different companies and individuals having exactly the same name (the original Amiga Forever catalog includes examples of both).

Similarly, for people, changes in name or gender do not affect the OID.

In case of indeterminacy due to duplication (e.g. transporter accidents, multiple restores from the same backup) additional OIDs should be issued to the new entities on a first-need first-serve basis.

Hardware

This subtree serves the purpose of cataloging all Amiga (and some non-Amiga) hardware.

For Amiga computers and consoles, preference should be given to assigning OIDs to unexpanded models. Peripherals and their own add-ons should be cataloged separately.

OIDs referencing aggregations of different (already-cataloged) hardware components may be assigned on a case by case basis, with great care to avoid introducing unnecessary complexity. This could be the case, for example, for Amiga systems consisting of an existing model and expansion board, and sold with a new model number in certain markets. In any case, care should be taken to catalog the individual components first, and to reference their OIDs in the new definition.

Given the possibility of future uncertainty about the exact model referenced by an OID, it is recommended to consider adding a specific product serial number to the item description, so as to have an unambiguous reference.

Pure ROM chips should be considered software, and not be cataloged as hardware. Identical hardware with different ROM versions should preferably maintain the same OID, and reference a different software version OID instead.

Prototypes can and should get their own OID under this subtree, unless they are identical with the final version, in which case they share the same OID.

This information is also used to define configurations in XADML files.

Official Publications and Data

This subtree is used to catalog all public and final released of software, books, CDs, compositions and other publications.

Hardware is in general excluded from this subtree, but ROMs are included.

Beta releases, and in particular software marked by Commodore as "Alpha", "Beta", "Gamma", as well as other non-public or interim releases of software should not be included in this subtree, but rather in the dedicated subtree (1.3.6.1.4.1.23153.1000.4). In case of doubt, items should be included in this subtree, unless explicitly marked "beta" or with a similar notice.

Individual issues of magazines and other periodicals should have their own OID. Before an OID is assigned to a specific issue, an OID should, if possible, be assigned to reference the series as a whole, and that OID should be referenced in the description of the specific issue. This does in general not apply to software released in multiple versions, but it may be applied on a case-by-case basis where the series needs to be referenced as a whole. The possibility of creating sub-subtrees is currently being considered for well-known series of magazines and software (e.g. Aminet CDs). Proposals are welcome.

For publications, if possible, the ISBN or ISSN number should be included in the item description.

For software, if possible, and in particular when referencing ROMs and titles which consist of one or more floppy disks or images thereof, it would be desirable to reference the CRC32 of the individual image(s) in the item description.

This information is also used to define configurations in XADML files.

Interim Publications and Data

This subtree is similar to the one dedicated to official publications and data (1.3.6.1.4.1.23153.1000.3), only that it serves the purpose of cataloging beta releases, unpublished works and other interim releases.

"Alpha", "Beta" and "Gamma" versions of the Amiga operating system and all software marked as beta fall under this subtree. A software version number beginning with "0", instead (e.g. "0.8.8"), should in general by itself not be used to imply beta status.

Delegated Maintenance Organizations

Having completed a first cataloging pass for the internal needs related to the Amiga Forever preservation project, and recognizing that many highly skilled Amiga enthusiasts and organizations exist which already specialize in topics covered by our effort, we are looking to delegate authority for the individual catalog subtrees.

Delegated entities will be listed on this page and in public OID registries.

If at any time an organization wishes to withdraw from the project, or is otherwise unable to keep maintaining the data, the subtree it maintains will become available for reassignment. The existing data set snapshot will be published as a text file or in a similar format, and transferred to the new maintainer.

Related Links

• XML-Based Application Description Information
• Use of XADML Files in Amiga Forever
• Amiga Configuration Identifiers
• Amiga Forever Manifesto