Storing non-MARC data in biblio_metadata
Hi all, How do people feel about storing non-MARC metadata in the biblio_metadata table? Typically, the "format" column contains the string "marcxml" and the "metadata" column contains the MARCXML text, but it seems like someone could put in "RDF/XML" and RDFXML text instead? The one barrier to that is the "marcflavour" column which is a "NOT NULL" column. I mean. that could be an empty string. but I wonder if there's a way of de-MARCing that column? I'm trying to think of analogs for other scenarios. I mean in the case of RDF. you might have RDF/XML or JSON-LD. which are separate formats but they're both "RDF". I wonder if "marcflavour" could be better known as "schema", or "model", or "standard", or something else? I know choosing wording is hard. For instance, MARC::File::XML (https://metacpan.org/pod/MARC::File::XML) refers to UNIMARC and MARC21 as formats. Dublin Core and MODS are often referred to as schemas. MARC21 is often called a standard. According to http://www.loc.gov/marc/unimarctomarc21.html, UNIMARC and MARC21 are formats. RDF gets called a data model with different data serialization formats. I know it would probably be a lot of work to change "marcflavour" to something else, especially since we've all been familiar with "marcflavour" for many years now, but I'm thinking maybe it's time we change that name. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595
It should be schema. We didn't want to change many things at a time in such a sensitive tables. It should probably pick Koha::MetadataRecord ideas. The main problem is making Koha aware of this in all senses. Definitely needs an RFC! Cheers El vie., 10 de ago. de 2018 05:44, David Cook <dcook@prosentient.com.au> escribió:
Hi all,
How do people feel about storing non-MARC metadata in the biblio_metadata table?
Typically, the “format” column contains the string “marcxml” and the “metadata” column contains the MARCXML text, but it seems like someone could put in “RDF/XML” and RDFXML text instead?
The one barrier to that is the “marcflavour” column which is a “NOT NULL” column. I mean… that could be an empty string… but I wonder if there’s a way of de-MARCing that column?
I’m trying to think of analogs for other scenarios. I mean in the case of RDF… you might have RDF/XML or JSON-LD… which are separate formats but they’re both “RDF”.
I wonder if “marcflavour” could be better known as “schema”, or “model”, or “standard”, or something else?
I know choosing wording is hard. For instance, MARC::File::XML ( https://metacpan.org/pod/MARC::File::XML) refers to UNIMARC and MARC21 as formats. Dublin Core and MODS are often referred to as schemas. MARC21 is often called a standard. According to http://www.loc.gov/marc/unimarctomarc21.html, UNIMARC and MARC21 are formats. RDF gets called a data model with different data serialization formats.
I know it would probably be a lot of work to change “marcflavour” to something else, especially since we’ve all been familiar with “marcflavour” for many years now, but I’m thinking maybe it’s time we change that name.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
_______________________________________________ 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/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
I don’t think we previously stored the marcflavour anywhere except in the systempreferences table though? A quick grep suggests that the biblio_metadata.marcflavour column is mostly unused at the moment? Changing the system preference “marcflavour” doesn’t seem feasible or even necessary (at least at this point), but I think changing the marcflavour column in the biblio_metadata table might not be too bad? I suppose a workaround could be to make an alias in the BiblioMetadata.pm file to point “schema” at “marcflavour”? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen@gmail.com] Sent: Friday, 10 August 2018 8:27 PM To: David Cook <dcook@prosentient.com.au> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Storing non-MARC data in biblio_metadata It should be schema. We didn't want to change many things at a time in such a sensitive tables. It should probably pick Koha::MetadataRecord ideas. The main problem is making Koha aware of this in all senses. Definitely needs an RFC! Cheers El vie., 10 de ago. de 2018 05:44, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Hi all, How do people feel about storing non-MARC metadata in the biblio_metadata table? Typically, the “format” column contains the string “marcxml” and the “metadata” column contains the MARCXML text, but it seems like someone could put in “RDF/XML” and RDFXML text instead? The one barrier to that is the “marcflavour” column which is a “NOT NULL” column. I mean… that could be an empty string… but I wonder if there’s a way of de-MARCing that column? I’m trying to think of analogs for other scenarios. I mean in the case of RDF… you might have RDF/XML or JSON-LD… which are separate formats but they’re both “RDF”. I wonder if “marcflavour” could be better known as “schema”, or “model”, or “standard”, or something else? I know choosing wording is hard. For instance, MARC::File::XML (https://metacpan.org/pod/MARC::File::XML) refers to UNIMARC and MARC21 as formats. Dublin Core and MODS are often referred to as schemas. MARC21 is often called a standard. According to http://www.loc.gov/marc/unimarctomarc21.html, UNIMARC and MARC21 are formats. RDF gets called a data model with different data serialization formats. I know it would probably be a lot of work to change “marcflavour” to something else, especially since we’ve all been familiar with “marcflavour” for many years now, but I’m thinking maybe it’s time we change that name. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/ -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
participants (2)
-
David Cook -
Tomas Cohen Arazi