I've been thinking along these lines too recently. I've been thinking 'wouldn't it be nice to do a No-SQL or directory hierarchy sort of thing where you just add subfields and attributes to the record as needed'. Of course in a relational database you would do that by having an attributed field that was serialized by some standard method. But you could only have non-critical information there, since it would have to be unserialized to query it. As far as indicators you would have to have some internally consistent way to map them to serialized attributes (and some subfields would be able to be handled that way too). For example with the indicator for MARC21 245$a you would have an attribute like 'ii',3 for 'indexing ignore first three characters', and you could do the same with authority id's instead of using $9 (of the top of my head) And of course you would have to have some framework(s) in order to convert the metadata to other formats (MARC21, UNIMARC, NORMARC, and DC for example), which would make the requirements for attributes quite large (to handle all the possible indicators and serializable subfields). Something like that I suppose.
On Sun, Nov 29, 2015 at 10:02 PM, Barton Chittenden < bar...@bywatersolutions.com> wrote: > >> >> >> 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/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ 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/
