+1 S. Meynieux -- Responsable support BibLibre + 33 (0)4 91 81 35 08 http://www.biblibre.com Le 17/11/2018 à 21:24, Tomas Cohen Arazi a écrit :

Or merge biblio and biblioitems ;-)

El sáb., 17 nov. 2018 a las 16:41, Barton Chittenden (<barton@bywatersolutions.com <mailto:barton@bywatersolutions.com>>) escribió:

Just out of curiosity, why does biblioitemnumber exist? There should be a one-to-one relationship between biblio records and biblioitem records ... so why not use biblionumber as the primary key for biblioitems?

--Barton _______________________________________________ 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 (http://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ 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/

Great info, Paul! We now removed the marc/marcxml columns from biblioitems too, so it makes more sense to merge them. El lun., 19 nov. 2018 a las 6:02, Paul Poulain (<paul.poulain@biblibre.com>) escribió:

<wise-old-man mode ON>

Koha v1.x has no MARC support. In fact, it was the first FRBR compliant software ever, long before FRBR exist... (who says Open Source is not innovative :D )

More explanation: in Koha v1, you had to enter a minimal biblio description (title, author(s), subject(s)) THEN one or more expression of the work (one large print, one readed book, one pocket, ...), THEN the different items. Very efficient and handy.

When I wrote the MARC code, I had to break this 3 level management (MARC has only 2 levels, biblio and items).

In Koha 2.0, you had the option to stay "basic" of "marc" cataloguing. It has been removed in Koha ??? (2.2 or 3.0 ?), only MARC cataloguing remained.

At this time biblioitems table became useless/should have been merged, but no one coded/hacked it. But yes, it can be removed (unless we want to keep it for future advanced support of FRBR :D )

<wise-old-man mode OFF>

Le 17/11/2018 à 20:40, Barton Chittenden a écrit :

...

Just out of curiosity, why does biblioitemnumber exist? There should be a one-to-one relationship between biblio records and biblioitem records ... so why not use biblionumber as the primary key for biblioitems?

--Barton

-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

_______________________________________________ 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 (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

If three levels are needed in the future, I'd start from a clean(er) slate and at least make sure they're named appropriately. --Ere Marcel de Rooy kirjoitti 19.11.2018 klo 15.08:

Three levels in BIBFrame again ?

*Van:* koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> *Namens *Tomas Cohen Arazi *Verzonden:* maandag 19 november 2018 14:02 *Aan:* Paul Poulain <paul.poulain@biblibre.com> *CC:* koha-devel <koha-devel@lists.koha-community.org> *Onderwerp:* Re: [Koha-devel] What is biblioitemnumber for?

Great info, Paul!

We now removed the marc/marcxml columns from biblioitems too, so it makes more sense to merge them.

El lun., 19 nov. 2018 a las 6:02, Paul Poulain (<paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>>) escribió:

<wise-old-man mode ON>

Koha v1.x has no MARC support. In fact, it was the first FRBR compliant software ever, long before FRBR exist... (who says Open Source is not innovative :D )

More explanation: in Koha v1, you had to enter a minimal biblio description (title, author(s), subject(s)) THEN one or more expression of the work (one large print, one readed book, one pocket, ...), THEN the different items. Very efficient and handy.

When I wrote the MARC code, I had to break this 3 level management (MARC has only 2 levels, biblio and items).

In Koha 2.0, you had the option to stay "basic" of "marc" cataloguing. It has been removed in Koha ??? (2.2 or 3.0 ?), only MARC cataloguing remained.

At this time biblioitems table became useless/should have been merged, but no one coded/hacked it. But yes, it can be removed (unless we want to keep it for future advanced support of FRBR :D )

<wise-old-man mode OFF>

Le 17/11/2018 à 20:40, Barton Chittenden a écrit : > Just out of curiosity, why does biblioitemnumber exist? There should > be a one-to-one relationship between biblio records and biblioitem > records ... so why not use biblionumber as the primary key for > biblioitems? > > --Barton

-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

_______________________________________________ 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 (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F

_______________________________________________ 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/

-- Ere Maijala Kansalliskirjasto / The National Library of Finland

Phew! :) Paul Poulain kirjoitti 19.11.2018 klo 15.41:

From my side it was a joke: we will integrate the new standards, no doubts, but we'll do it more cleanly than using biblio/biblioitems/items !

Le 19/11/2018 à 14:39, Ere Maijala a écrit :

...

If three levels are needed in the future, I'd start from a clean(er) slate and at least make sure they're named appropriately.

-- Ere Maijala Kansalliskirjasto / The National Library of Finland

Paul, very interesting the basic historic idea. What you wrote, helps me to say that with Elasticsearch, Koha has the possibility to adopt definitely the LRM [1] model, that is going to be implemented in RDA [2]. Especially important IMHO are links among authorities. Or, better, links of any type. Stefano [1] https://www.ifla.org/publications/node/11412 [2] http://www.rda-rsc.org/ImplementationLRMinRDA

On 19 Nov 2018, at 14:39, Ere Maijala <ere.maijala@helsinki.fi> wrote:

If three levels are needed in the future, I'd start from a clean(er) slate and at least make sure they're named appropriately.

--Ere

Marcel de Rooy kirjoitti 19.11.2018 klo 15.08:

...

Three levels in BIBFrame again ? *Van:* koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> *Namens *Tomas Cohen Arazi *Verzonden:* maandag 19 november 2018 14:02 *Aan:* Paul Poulain <paul.poulain@biblibre.com> *CC:* koha-devel <koha-devel@lists.koha-community.org> *Onderwerp:* Re: [Koha-devel] What is biblioitemnumber for? Great info, Paul! We now removed the marc/marcxml columns from biblioitems too, so it makes more sense to merge them. El lun., 19 nov. 2018 a las 6:02, Paul Poulain (<paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>>) escribió: <wise-old-man mode ON> Koha v1.x has no MARC support. In fact, it was the first FRBR compliant software ever, long before FRBR exist... (who says Open Source is not innovative :D ) More explanation: in Koha v1, you had to enter a minimal biblio description (title, author(s), subject(s)) THEN one or more expression of the work (one large print, one readed book, one pocket, ...), THEN the different items. Very efficient and handy. When I wrote the MARC code, I had to break this 3 level management (MARC has only 2 levels, biblio and items). In Koha 2.0, you had the option to stay "basic" of "marc" cataloguing. It has been removed in Koha ??? (2.2 or 3.0 ?), only MARC cataloguing remained. At this time biblioitems table became useless/should have been merged, but no one coded/hacked it. But yes, it can be removed (unless we want to keep it for future advanced support of FRBR :D ) <wise-old-man mode OFF> Le 17/11/2018 à 20:40, Barton Chittenden a écrit : > Just out of curiosity, why does biblioitemnumber exist? There should > be a one-to-one relationship between biblio records and biblioitem > records ... so why not use biblionumber as the primary key for > biblioitems? > > --Barton -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries _______________________________________________ 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 (http://theke.io <http://theke.io/>) ✆+54 9351 3513384 GPG: B2F3C15F _______________________________________________ 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/

-- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ 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/

Hello Stefano, What you're pointing Stefano is very important: we must start our effort toward LRM. Here is my 1st thoughts about it: I think that LRM support on Koha means 2 things: * internal handling of the LRM model. This would mean breaking the biblio/items structure of the database, managing "LRM records" (if we have), proposing LRM cataloguing tools, and changing many many other things in Koha (like MARC staging, z39/50 search, ...) I feel that this will require years and a lot of work, and for now the national catalogs are not ready to propose that. * new search paradigm. What the Oslo Public Library made is very interesting. when you do a search, you get the works (author/title/copyright date), then can see the expressions that exists in the library (publication dates, material type/support), then the items. Example: XXXXX I don't know in US, italy or other countries, but in France the BNF is working hard on adding "LRM" fields in their catalogue. This is done by adding new MARC fields (a lot...), that will contain an ARK to the linked data (work, authors, place, subject, ...). Last week, there was a meeting at the BNF where they presented their plans for 2019. BibLibre has not yet started to investigate the effort to create a "LRM-UNIMARC-Elastic Search" in Koha, but, for sure that's something we'll investigate in 2019. If anyone is willing to join the effort, let me know (even better: if you are interested in LRM-MARC21-Elastic, the idea being to have a flexible configuration). If anyone has information regarding LRM-MARC21-LoC plans, feel free to share ! Have I missed something ? What are your plan regarding IFLA-LRM ? What's next ? Le 19/11/2018 à 16:58, Stefano Bargioni a écrit :

Paul, very interesting the basic historic idea. What you wrote, helps me to say that with Elasticsearch, Koha has the possibility to adopt definitely the LRM [1] model, that is going to be implemented in RDA [2]. Especially important IMHO are links among authorities. Or, better, links of any type. Stefano

[1]https://www.ifla.org/publications/node/11412 [2]http://www.rda-rsc.org/ImplementationLRMinRDA

-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

Recently, I used a discovery layer for a public library of which I’m a member, and I was so frustrated, as the search interface was so poorly designed. I spent minutes trying to find my resource but I couldn’t do anything but put keywords into a box, which did not retrieve the resource. Fortunately, I was able to fallback to their legacy catalogue where the search only took me 2 seconds to find the resource. But it’s a reminder that the people who matter most are the users of the library system. If that library loses their legacy catalogue, I’ll probably just stop using that library, as the discovery layer search interface was useless. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: David Cook [mailto:dcook@prosentient.com.au] Sent: Wednesday, 21 November 2018 12:30 PM To: 'Paul Poulain' <paul.poulain@biblibre.com>; 'koha-devel@lists.koha-community.org' <koha-devel@lists.koha-community.org> Subject: RE: [Koha-devel] roadmap to LRM support ? [was Re: What is biblioitemnumber for?] I can’t speak to LRM at all, but it reminds me how perhaps we should start moving towards uncoupling some parts of Koha and thinking more about how the different aspects should/could interact with different metadata models. I think Paul has already targeted the most important thing and that’s search. Users don’t care what metadata model is in Koha. They just want to be able to find the resources they desire. So whatever we do… I think we should put OPAC users of Koha first and then work backwards. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul Poulain Sent: Tuesday, 20 November 2018 11:58 PM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: [Koha-devel] roadmap to LRM support ? [was Re: What is biblioitemnumber for?] Hello Stefano, What you're pointing Stefano is very important: we must start our effort toward LRM. Here is my 1st thoughts about it: I think that LRM support on Koha means 2 things: * internal handling of the LRM model. This would mean breaking the biblio/items structure of the database, managing "LRM records" (if we have), proposing LRM cataloguing tools, and changing many many other things in Koha (like MARC staging, z39/50 search, ...) I feel that this will require years and a lot of work, and for now the national catalogs are not ready to propose that. * new search paradigm. What the Oslo Public Library made is very interesting. when you do a search, you get the works (author/title/copyright date), then can see the expressions that exists in the library (publication dates, material type/support), then the items. Example: XXXXX I don't know in US, italy or other countries, but in France the BNF is working hard on adding "LRM" fields in their catalogue. This is done by adding new MARC fields (a lot...), that will contain an ARK to the linked data (work, authors, place, subject, ...). Last week, there was a meeting at the BNF where they presented their plans for 2019. BibLibre has not yet started to investigate the effort to create a "LRM-UNIMARC-Elastic Search" in Koha, but, for sure that's something we'll investigate in 2019. If anyone is willing to join the effort, let me know (even better: if you are interested in LRM-MARC21-Elastic, the idea being to have a flexible configuration). If anyone has information regarding LRM-MARC21-LoC plans, feel free to share ! Have I missed something ? What are your plan regarding IFLA-LRM ? What's next ? Le 19/11/2018 à 16:58, Stefano Bargioni a écrit : Paul, very interesting the basic historic idea. What you wrote, helps me to say that with Elasticsearch, Koha has the possibility to adopt definitely the LRM [1] model, that is going to be implemented in RDA [2]. Especially important IMHO are links among authorities. Or, better, links of any type. Stefano [1] https://www.ifla.org/publications/node/11412 [2] http://www.rda-rsc.org/ImplementationLRMinRDA -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

I agree with the idea of catalinking, and/but I think that most of the catalinking will be done by national repos (like BNF, LoC, ...) That's why I think/feel that we should focus on linked data display first. And that's one of the reason why we (BibLibre) started the "Explore" project (see my talk at the KohaCon18 : https://www.youtube.com/watch?v=bIByWcvIj5Q) we're continuing to investigate, try, fail, retry, ... I also think that academic library point of view will differ a little bit from public library pov. Le 21/11/2018 à 13:07, Stefano Bargioni a écrit :

I also like to speak from a "cataloguer first" point of view. I mean: with RDA and LRM, cataloguing is moving to ... catalinking [1]. It is an intellectual job, that the staff UI has to support. Of course, in the background a robust data structure (oriented to objects and links among them) is required. And good (linked) data are IMHO necessary to build a powerful search interface. So, can Koha evolve up to this vision, where maybe Bibframe and MARC21+RDA have to be present at the same time? A lot of work, I'm sure, that requires (not only) new funds. Ciao. Stefano

[1] https://www.flickr.com/photos/steveb59/14262929380/in/album-7215764875791780...

...

On 21 Nov 2018, at 02:32, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au>> wrote:

Recently, I used a discovery layer for a public library of which I’m a member, and I was so frustrated, as the search interface was so poorly designed. I spent minutes trying to find my resource but I couldn’t do anything but put keywords into a box, which did not retrieve the resource. Fortunately, I was able to fallback to their legacy catalogue where the search only took me 2 seconds to find the resource. But it’s a reminder that the people who matter most are the users of the library system. If that library loses their legacy catalogue, I’ll probably just stop using that library, as the discovery layer search interface was useless. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 *From:*David Cook [mailto:dcook@prosentient.com.au] *Sent:*Wednesday, 21 November 2018 12:30 PM *To:*'Paul Poulain' <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>>; 'koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org>' <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org>> *Subject:*RE: [Koha-devel] roadmap to LRM support ? [was Re: What is biblioitemnumber for?] I can’t speak to LRM at all, but it reminds me how perhaps we should start moving towards uncoupling some parts of Koha and thinking more about how the different aspects should/could interact with different metadata models. I think Paul has already targeted the most important thing and that’s search. Users don’t care what metadata model is in Koha. They just want to be able to find the resources they desire. So whatever we do… I think we should put OPAC users of Koha first and then work backwards. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 *From:*koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org>[mailto:koha-devel-bounces@lists.koha-community.org]*On Behalf Of*Paul Poulain *Sent:*Tuesday, 20 November 2018 11:58 PM *To:*koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> *Subject:*[Koha-devel] roadmap to LRM support ? [was Re: What is biblioitemnumber for?]

Hello Stefano,

What you're pointing Stefano is very important: we must start our effort toward LRM.

Here is my 1st thoughts about it: I think that LRM support on Koha means 2 things:

* internal handling of the LRM model. This would mean breaking the biblio/items structure of the database, managing "LRM records" (if we have), proposing LRM cataloguing tools, and changing many many other things in Koha (like MARC staging, z39/50 search, ...) I feel that this will require years and a lot of work, and for now the national catalogs are not ready to propose that. * new search paradigm. What the Oslo Public Library made is very interesting. when you do a search, you get the works (author/title/copyright date), then can see the expressions that exists in the library (publication dates, material type/support), then the items. Example: XXXXX I don't know in US, italy or other countries, but in France the BNF is working hard on adding "LRM" fields in their catalogue. This is done by adding new MARC fields (a lot...), that will contain an ARK to the linked data (work, authors, place, subject, ...). Last week, there was a meeting at the BNF where they presented their plans for 2019. BibLibre has not yet started to investigate the effort to create a "LRM-UNIMARC-Elastic Search" in Koha, but, for sure that's something we'll investigate in 2019. If anyone is willing to join the effort, let me know (even better: if you are interested in LRM-MARC21-Elastic, the idea being to have a flexible configuration). If anyone has information regarding LRM-MARC21-LoC plans, feel free to share !

Have I missed something ? What are your plan regarding IFLA-LRM ? What's next ?

Le 19/11/2018 à 16:58, Stefano Bargioni a écrit :

...

Paul, very interesting the basic historic idea. What you wrote, helps me to say that with Elasticsearch, Koha has the possibility to adopt definitely the LRM [1] model, that is going to be implemented in RDA [2]. Especially important IMHO are links among authorities. Or, better, links of any type. Stefano [1]https://www.ifla.org/publications/node/11412 [2]http://www.rda-rsc.org/ImplementationLRMinRDA -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

---

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/

_______________________________________________ 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/

-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries