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

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/