[db-wg] proposal: haiku object

Shane Kerr wrote:
> 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). 

A low blow.... and also one that is incorrect. Look again, "serenaders"
rhymes (or is more strictly an assonance) with "made us". The last line
"join in" rhymes with "the din".

Some sort of soundex scheme would possibly have found this... however I
agree that this is not an easy problem.

> 
> 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.

Well, as you know, I'm not at all sure that limericks are *required* to be
humourous. I agree that the database definition says they are, but I feel
that this is too limiting. I would propose modification of the specification
to be "usually humourous". Of course if the verse-form proposal below is
adopted, this can be dealt with in the descriptive limerick. 

> 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 at ripe.net 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 at ripe.net 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?

I personally wouldn't trust ICANN to create any verse-form other than a
writ, although in mitigation, we have an ex-speaker for the secret working
group embedded as a mole within the organisation, and now may be the time to
activate him.

> 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.

Oh quite. Perhaps the RIPE NCC could come up with a migration plan. 

I think the above is an excellent proposal, and I further endorse the later
suggestion that the description be in the verse form itself.

Best regards 

-- 
Nigel Titley
Peering Coordinator, FLAG Telecom
+44 20 7478 9579


**********************************************************************
This e-mail message is confidential and is intended only for the use of the
individual or entity named above and contains information which is or may be
confidential, non-public or legally privileged. Any dissemination or
distribution of this message other than to its intended recipient is
strictly prohibited. You should not copy it or use it for any purpose nor disclose 
the contents to any other person. If you have received this message in error, please
notify us by email to postmaster at flagtelecom.com immediately and delete the
original message and all copies from all locations in your computer systems.


This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG
Telecom cannot accept liability for any damage which you may sustain as a
result of software viruses.
**********************************************************************

  



This message has been scanned for viruses by MailControl - www.mailcontrol.com