Shane, On Thu, Jan 23, 2003 at 12:42:49PM +0100, ext Shane Kerr wrote:
An organisation object in the RIPE Database --------------------------------------------
1. Motivation -----------
Currently the RIPE Database stores two main types of contact information: person and role objects.
These provide a way to contact people responsible for operations or usage of the resources whose data is presented in the RIPE Database (IP blocks, autonomous systems, and domain names).
However, none of these provide an easy way of mapping resources to a particular organisation. A user looking up data must first find an object containing information about a contact point at that organisation and then, assuming all of that organisation's objects refer to this contact information, perform an inverse query on the Database to obtain a list of objects referencing the specified person or role.
This level of indirection can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation can be seen as a useful addition to the RIPE Database.
This document is a proposal for an organisation object in the RIPE Database and the corresponding needed database functionality.
I don't understand why we need yet another object that has very simular functionality as the role/person object. Why don't we fix the role object if there is a problem with the role object ?!? Or, why don't we retire the role object and replace it with an organization object. Adding yet another object, while keeping a deficient object seems not the best route to me. Let's first fix what we have or get rid of it before we start adding new objects. Having three different objects that all have very simular but not exactly the same functionality will only add to the confusion. Yes, you can keep adding objects for all kind of special needs, but there comes a point where it's impossible for regular humans to deal with the database because they don't understand the fine differences of all the different contact objects and special obscure attributes. David K. ---