Re: [Koha-devel] Proposed "metadata" table for Koha
For now, I think the metadata.record_id would link to biblionumber, but long-term it would probably link to some “record” table. So if you wanted to get all bibliographic records, you’d do something like: select * from record join metadata ON record.id = metadata.record_id where record.type = ‘bibliographic’ Or maybe you want to search for a bibliographic record with a 001 of 123456789: select * from record join metadata ON record.id = metadata.record_id where record.type = ‘bibliographic’ and metadata.qualifier = ‘001’ and metadata.value = ‘123456789’ -- 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. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com] Sent: Monday, 30 November 2015 2:17 PM To: David Cook <dcook@prosentient.com.au> Subject: Re: [Koha-devel] Proposed "metadata" table for Koha
The basic schema I have in mind would be something like: metadata.id <http://metadata.id> , metadata.record_id, metadata.scheme, metadata.qualifier, metadata.value.
The row would look like: 1, 1, marc21, 001, 123456789
I think this is an interesting idea... Obviously the replication of biblio data is not ideal, but I think that that's a necessary and worthwhile trade off in terms of moving away from MARC. How do you propose linking the metadata fields to the biblio records? Does the metadata.record_id link to biblionumber?
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
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 < barton@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
participants (3)
-
Barton Chittenden -
David Cook -
Michael Hafen