search

bic-org-uk / bic-lcf

BIC Library Communication Framework
https://bic-org-uk.github.io/bic-lcf
Other
7 stars 4 forks source link

Clarification on use of "structured-name" (E03C36) #286

Closed MarkOliver closed 1 year ago

MarkOliver commented 3 years ago

We are implementing a client that uses LCF to connect to an LMS system that implements LCF 1.2. We have hit an issue where the name being represented in a single field (E03D22, "name") causes us difficulty as it is not divided into given name and surname.

The next version of LCF appears to address this issue and implements a new "structured-name" field (E03C36). I've have some questions about this:

  1. Will systems that implement this new version of LCF have to provide the name in both the pre-formatted single field ("name") and the new structured data "structured-name" elements? Or will it be left up to the implementers about which fields they use? Obviously we would prefer the former, that the structured data must be provided by a system that implements LCF.
  2. When most users have just a given name and a surname is it expected that given name, e.g. "John", would be in "names-before-key" and the surname, e.g. "Smith", would be in "key-names". Looking at the ONIX specification this seems to be correct, surname would be what is used to open the entry in an alphabetical list.
franciscave commented 3 years ago

@MarkOliver. element E03D22 Name remains mandatory in all instances of E03 Patron, so the answer to your first question is that implementers must continue to provide the unstructured name of the patron, but the new structure E03C36 is non-mandatory. If we were to make E03C36 mandatory, this would be a non-backwards-compatible change to LCF, which could only be included in a major version change to LCF, i.e. moving from LCF 1.x.x to LCF 2.x.x. What we might be able to do is to make it a requirement of the REST implementation that, if the LCF version is reported to be 1.x.x or later, the server must implement E03C36.

Regarding your second question, yes, the patron's surname would be in "key-names" and the patron's given name would usually be in "names-before-key". Examples can be found in the ONIX 3.0 Implementation and Best Practice Guide, under the section describing how to represent authors' names in ONIX.

MarkOliver commented 3 years ago

Thanks for those answers.

Having the name split into given name and surname is incredibly valuable to us as surname is what people will search upon. So any way of making the structured data mandatory, be that in LCF 2.x.x or as a part of the REST implementation requirements, would be very much appreciated.

mdovey commented 2 years ago

Agreed by the technical panel on 3/11/2021 to make support for both structured and unstructured name mandatory for servers, clients may choose which to use.

franciscave commented 2 years ago

I propose the following change in the specification of entity E03 Patron in the LCF Data Framework (new text is shown below in bold and in square brackets - why doesn't Github Markdown support underlining?):

E03 PATRON

...

Properties

Id Element SIP2 ID Card. Format Description
... ... ... ... ... ...
E03D22 Name AE 1 String Name of primary contact for this patron.
Added in v1.0.1
E03C36 Structured name 0-1 Name of primary contact in structure form, following the model provided by ONIX. Only for use with personal names. Note that, for display purposes, structured names would normally be re-assembled in the order specified here.
[Mandatory in server responses.]
Added in vx.x.0

Should a similar change also be made in the XML binding for E03 Patron? My recommendation is not to do so: it is generally a bad idea to specify the same requirement in two places, because this carries the risk of them ending up contradicting each other when one is changed and the other not.

Should E03D22 Name be non-mandatory in client requests, but with the requirement that either E03D22 or E03C36 must be included?

franciscave commented 2 years ago

In the Technical Meeting of 11 October 2022 it was agreed that, while it is desirable for structured names to be mandatory in server responses, this would be a major change and should not therefore be made in a minor revision of LCF. However, it was thought worthwhile to incorporate a note in the next minor revision indicating that structured names are planned to be mandatory in server responses in the next major revision of LCF.

As a consequence, the proposed change is modified as shown below:

E03 PATRON

...

Properties

Id Element SIP2 ID Card. Format Description
... ... ... ... ... ...
E03D22 Name AE 1 String Name of primary contact for this patron.
Added in v1.0.1
E03C36 Structured name 0-1 Name of primary contact in structured form, following the model provided by ONIX. Only for use with personal names. Note that, for display purposes, structured names would normally be re-assembled in the order specified here.
Added in vx.x.0
NOTE: At the next major revision of LCF it is proposed to make this element mandatory in server responses.

It should also be noted that, contrary to what I said in the Technical Panel meeting, structured names for Patrons are not included in the current released version of LCF. All the more reason to postpone for the time being making this element mandatory in server responses.