Re: [db-wg] proposal: haiku object

[Shane Kerr <]

Titley, Nigel wrote:
> Does the RIPE NCC have a view
> On provision of objects haiku?
> Are you bored and depressed
> And in need of a rest?
> Is this just too much extra to do?
I think that I shall never see,
A class as lovely as a tree.
  Trees like ash and bitternut,
  May be only made by God but,
Objects are made by fools like me.

[ With apologies to Alfred Joyce Kilmer ]


Anyway, we are certainly willing to implement any feature that the 
community thinks is necessary, including but not limited to new classes, 
attributes, access methods, etc.


Having said that, we have some problems with the current limerick class.

First, we are having trouble coming up with a good way to detect whether 
limerick contents match the rhyming scheme.  We can implement this, 
although we will probably limit it to English (even though there are 
Dutch, French, German, and other limericks), and will have to make it a 
warning rather than an error, to allow for artistic leave (to help people 
who think that "serenaders" rhyme with "join us", like in LIM-NT13-1).

Second, it is difficult for us to enforce the requirement that the poem is 
humorous.  I tried various algorithms, but none of the software I came up 
with seemed to find any of the limericks funny at all.  Actually, I 
thought my computer was angry enough to swear at me, until I remembered 
that I had tried Perl, and the punctuation symbols were just the program 
itself.


Anyway, I find the haiku an interesting proposal, but I do like the 
generality of the poem proposal.  I also agree that limiting the types of 
poems to a pre-defined set of types.  Therefore I suggest we use the 
database to self-document the types of poems using a meta-poem object.  So 
poems would look like this:

poem:          [mandatory]  [single]     [primary/look-up key]
descr:         [optional]   [multiple]   [ ]
form:          [mandatory]  [single]     [inverse key]
text:          [mandatory]  [multiple]   [ ]
admin-c:       [mandatory]  [multiple]   [inverse key]
author:        [mandatory]  [multiple]   [inverse key]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]
mnt-by:        [mandatory]  [multiple]   [inverse key]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

The "form:" attribute will reference a poetic-form object:

poetic-form:   [mandatory]  [single]     [primary/look-up key]
descr:         [optional]   [multiple]   [ ]
admin-c:       [mandatory]  [multiple]   [inverse key]
tech-c:        [mandatory]  [multiple]   [inverse key]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]
mnt-by:        [mandatory]  [multiple]   [inverse key]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

The "descr:", "admin-c:", "tech-c:", "remarks:", "notify:", "mnt-by:", 
"changed:", and "source:" attributes are required in all RPSL objects 
according to RFC 2622.

Initially we would have:

poetic-form: VERSE-LIMERICK
desr:        A limerick object represents a humorous poem that has five
             lines and the rhyme scheme "aabba".
admin-c:     LIM1-RIPE
tech-c:      LIM1-RIPE
mnt-by:      RIPE-DBM-MNT
changed:     ripe-dbm@localhost 20040401
source:      RIPE

poetic-form: VERSE-HAIKU
descr:       A haiku object represents a poem that usually has three
             lines with 5, 7 and 5 units. In languages other than Japanese
             units are generally applied as syllables.
             There is no rhyme scheme at all.
admin-c:     HIKU1-RIPE
tech-c:      HIKU1-RIPE
mnt-by:      RIPE-DBM-MNT
changed:     ripe-dbm@localhost 20040401
source:      RIPE

We would restrict new poetic-form objects to creation by RIPE DBM, but 
adding additional forms for sonnets, free verse, blank verse, and so on, 
should be easy.  If the community feels that identifying and documenting 
poetic forms falls out of the scope of the RIPE NCC activities, we can 
consider an alternative mechanism.  Perhaps ICANN would be able to perform 
this activity?

In any case, we would need a conversion project to change the existing 
limerick objects into poem objects.  There are currently 152 of these, so 
we need to be careful not to interfere with these in a way that affect the 
production services that depend on them.

FYI, the easy way to see all limericks to date is to get:

ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.limerick.gz


An alternative path may be to consider encouraging haiku fans to author 
poems that also qualify as limericks:

http://www.bluejo.demon.co.uk/poetry/interstichia/haiku.htm

--
Shane Kerr
RIPE NCC