RE: [db-wg] proposal: haiku object
Robert S. Plaul <mailto:robert@plaul.de> wrote:
Proposal for Adding a Haiku Object to the RIPE Database
Requirement:
System Administrators and other users of the RIPE Database need some avocation beside their exhausting work with ip address space assignments, routing and other occupations concerning database objects which have to be taken seriously. The existing limerick object provides such avocation but obviously has some limitations:
[...]
Solution:
... Even Though I fully agree with the need for a haiku object, because I am not sure of my limmericks (LIM-ROSE LIM-FRIENDS LIM-STRESS) I don't think the creation of an haiku object -per se- might be the solution. Mayhaps can we reuse the limerick objects and use the remarks field with one of the possible value : HAIKU, for haiku SONNET for such PROSE for freestyle poetry .... Therefore not only would we satisfy : - sysadmin that like well labelled object for easier retrieval, - poets for increasing their potentiality, - RIPE dba for not chaging the actual object. And if an object was to be created I would propose on the model of limerick object whois -t poem poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] type: [mandatory] [single] [ ] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Where type would be one of the folllowing : LIMERICK, PROSE, QUATRAIN, SONNET, HAIKU, ASCII-ART ... Such a solution would broadly sataisfy any sysadmin wanting to express his art freely. For managers I would propose a MEMO object too. Because, the whois DB might be the fully legitimate place for such a thing, the last place where you are gonna search for such an abomination. ;) Regards, Julien Tayon
Hi,
And if an object was to be created I would propose on the model of limerick object
Since I am always in favour of a general approach, I support the Poem Object.
whois -t poem
poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] type: [mandatory] [single] [ ] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Where type would be one of the folllowing : LIMERICK, PROSE, QUATRAIN, SONNET, HAIKU, ASCII-ART ...
Such a solution would broadly sataisfy any sysadmin wanting to express his art freely.
is there a deep reason for this beeing the only object not haveing a tech-c: ? Meaning the one who created the poem (i.e. admin-c) might not be the one manageing it (i.e. tech-c).
For managers I would propose a MEMO object too. Because, the whois DB might be the fully legitimate place for such a thing, the last place where you are gonna search for such an abomination. ;)
and in that context the official ORDER object too. like Manager: I gave you an order! Admin: Where? Manager: in 'ORDER-CONNECT-CUSTOMER' SCNR lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Mon, 8 Mar 2004, TAYON, Julien wrote:
Even Though I fully agree with the need for a haiku object, because I am not sure of my limmericks (LIM-ROSE LIM-FRIENDS LIM-STRESS)
aehm, yes, i think they are no limericks, besides the fact, that you should use multiple text: lines instead of one...
I don't think the creation of an haiku object -per se- might be the solution. Mayhaps can we reuse the limerick objects and use the remarks field with one of the possible value : HAIKU, for haiku SONNET for such PROSE for freestyle poetry
I can fully understand, that you prefer a more generic solution. However, the remarks: field idea is IMHO not a very good solution. Just read the mails in the abuse-c threads about abuse contact information in remark: fields of inet(6)num objects...
Therefore not only would we satisfy : - sysadmin that like well labelled object for easier retrieval,
Inverse queries for text in remark: fields? hmmm...
- RIPE dba for not chaging the actual object.
One advantage of my haiku object is, that its definition is - more or less - a copy of existing limerick object.
And if an object was to be created I would propose on the model of limerick object
whois -t poem
poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] type: [mandatory] [single] [ ] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Where type would be one of the folllowing : LIMERICK, PROSE, QUATRAIN, SONNET, HAIKU, ASCII-ART ...
I'm not sure about whether I think it is a good idea to have dozens of different poem types in the database. Maybe we should focus on a few types with extraordinary popularity. (I think this are the limerick and the haiku...) Just before anyone asks for it: I am against ANSI-ART in the database ;-)
For managers I would propose a MEMO object too. Because, the whois DB might be the fully legitimate place for such a thing, the last place where you are gonna search for such an abomination. ;)
The whois client as PIM application. I'm curious, what the database administration is going to say about that... Robert -- RSP-RIPE
participants (3)
-
Robert S. Plaul -
TAYON, Julien -
Ulrich Kiermayr