[Koha-devel] Proposed "metadata" table for Koha

[Barton Chittenden]

>
>
>
>
> Of course, off the top of my head, I don’t know how you’d store indicators
> and subfields in an extensible way. I suppose indicators are attributes and
> subfields are child elements...
>
>
>
> I suppose DSpace actually does a “element” and “qualifier” approach for
> DC. So you’d have a “dc”, “author”, “primary”. Or “marc21” “100” “a”. Of
> course, that creates a limit of a single level of hierarchy which may or
> may not be desirable… and still doesn’t account for indicators/attributes.
>
>
>
> I suppose there is more thinking to do there.
>

My mind flew off into several different schemes for recursively
sub-dividing metadata. I had to reboot my brain because I ran out of stack
space. Dang infinite recursion. This reminded me of a Larry Wall quote ...
my memory of the quote was about abstraction, but there was a bit more to
it:

 I think that the biggest mistake people make is latching onto the first
> idea that comes to them and trying to do that. It really comes to a thing
> that my folks taught me about money. Don't buy something unless you've
> wanted it three times. Similarly, don't throw in a feature when you first
> think of it. Think if there's a way to generalize it, think if it should be
> generalized. Sometimes you can generalize things too much. I think like the
> things in Scheme were generalized too much. There is a level of abstraction
> beyond which people don't want to go. Take a good look at what you want to
> do, and try to come up with the long-term lazy way, not the short-term lazy
> way.


So... what's the long-term lazy way of handling the sub-division of
metadata?

--Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20151130/64e3cff5/attachment.html>