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
