Extension of the properties of a Location

[dkarvel]

Hi,

I'd like to recommend we include additional properties of a Location element

The additional properties will include information about :

1. If it is a reservation pickup location (where patrons can pickup the held items)
2. If the location can be a patron's home location.
3. If the Location is hidden i.e. from searching manifestations

At the moment we are using the LibraryType to define some of the above parameters or even the Note field.

Thank you,

[franciscave]

1. Reservation pickup location is already covered by E06D08 Pickup location reference.
2. Patron's home location, if you're referring to their home library/institution, is already covered by E03D03.1 Location association type with code value LAT03. If you're referring to their postal address, LCF v1.0.1 defines this using a Contact entity (E09), which can be used repeatedly with a Patron entity to define their contact details.
3. This is an interesting proposal. "Hidden" is a property of a Location that is different from its type. I think that a Location could be specified to be hidden or not, regardless of the type of Location. But possibly the Location would be hidden for some purposes and not for others, e.g. dependent upon the identity of the terminal in use or the end-user. I'd welcome comments from others on this proposal.

[franciscave]

To further clarify my response to proposal 2: to represent a Patron's home address, one would add a Contact reference to the Patron record, and in the Contact record include communication details of type CMT06 (postal address). The Contact record can point back to the Patron record.

[dkarvel]

Hi Francis, Thank you for your response and approving the third property "hidden location".

My recommendation on the other two properties still stand as it is about the Location entity therefore properties that come when we retrieve the list of locations.

For example we need to retrieve from the LMS the List of Locations that an item can be picked up from or the list of locations that can be a user home.

Therefore we need something like a list of , ,

, , booleanIsthisLocationAPickUpLocation, booleanIsthisLocationHidden, booleanIsThisLocationAHomeLocation? Please feel free to advise me if the list of locations can currently provide that sort of properties so we can filter based on those properties. I do appreciate the effort and work going into a fairly new standard and as a long time member of the SIP3 definition standard (years ago) I do understand the hard work going in behind the new standard. Thank you. Dimitris Karvelis On Thu, 8 Nov 2018 at 01:47, Francis Cave wrote: > > 1. Reservation pickup location is already covered by E06D08 Pickup > location reference. > 2. Patron's home location, if you're referring to their home > library/institution, is already covered by E03D03.1 Location association > type with code value LAT03. If you're referring to their postal address, > LCF v1.0.1 defines this using a Contact entity (E09), which can be used > repeatedly with a Patron entity to define their contact details. > 3. This is an interesting proposal. "Hidden" is a property of a > Location that is different from its type. I think that a Location could be > specified to be hidden or not, regardless of the type of Location. But > possibly the Location would be hidden for some purposes and not for others, > e.g. dependent upon the identity of the terminal in use or the end-user. > I'd welcome comments from others on this proposal. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

[franciscave]

Hi Dimitris

Thank you for your further explanation. Regarding your first request, can I ask whether you would be looking to retrieve all locations from which ANY reserved item can be picked up, or to retrieve all locations from which A SPECIFIC item can be picked up? The former could be achieved by characterising a Location as being of type "pick-up location", which as you suggest would only be feasible if we were to add an extra element to the Location entity. The latter could be achieved by retrieving all current and past Reservations of the specific Item, then searching for all Locations associated with these Reservations for which the association type is LAT03.

Regarding your second request, in LCF we have taken the view that a Patron's home address is not a Location as such, but a communication identifier as a means of contacting a Patron. There's no guarantee that a Patron's postal address is a physical Location, e.g. it could be a PO Box or a "care-of" address. I'd be interested in the views of others on this point, but it strikes me that there could be privacy-related concerns about trying to identify home locations of library patrons.

[franciscave]

One could, of course, retrieve all Contact entities for all Patron entities and extract from these all communication identifiers of type "postal address". That would be a round-about way of achieving what I think you are requesting.

[dkarvel]

Thanks again Francis,

In regards to the first request: The former, which is: retrieve all locations from which ANY reserved item can be picked up This will be used on User Interface designs where we offer the ability for one to choose the location they can pickup any item.

Regarding your second request. I probably confused you with the term "Home" Location. Home location is not the address of a patron. "Home" is a location property describing which branch is my preferred location. Although a patron has one or many preferred locations (branch/es) where they usually visit the library and most likely they will collect their reservations.

So, please rename my requested property from "Home Location" to "Preferred location".

Now, it is important to understand that although at first this seems to be a Patron's property it is also a Location property as some branches e.g. a book depot (not a branch) cannot be a Preferred Location.

So, when a user is registering online for the first time we would like to present the patron with a list that he/she choose as their preferred "Home" Branch. The terminology is related to IsReservible or IsHidden somehow but those other two properties are not exclusive. e.g. City Of Sydney in Australia has a bok collection depot as a location which is searchable (not hidden), It is not a pickup address (they have to move the chosen items to another branch for pickup) and it is not a preferred "Home Branch" location.

Please see my request from the List of Locations point of view. I hope this clarifies a bot more the need of marking a Location as a possible "Preferred Branch". This is not a contact as in Patron's postal or residential address. Thank you and apologies for my limited ability to explain,

Dimitris

On Thu, 8 Nov 2018 at 19:59, Francis Cave notifications@github.com wrote:

Hi Dimitris

Thank you for your further explanation. Regarding your first request, can I ask whether you would be looking to retrieve all locations from which ANY reserved item can be picked up, or to retrieve all locations from which A SPECIFIC item can be picked up? The former could be achieved by characterising a Location as being of type "pick-up location", which as you suggest would only be feasible if we were to add an extra element to the Location entity. The latter could be achieved by retrieving all current and past Reservations of the specific Item, then searching for all Locations associated with these Reservations for which the association type is LAT03.

Regarding your second request, in LCF we have taken the view that a Patron's home address is not a Location as such, but a communication identifier as a means of contacting a Patron. There's no guarantee that a Patron's postal address is a physical Location, e.g. it could be a PO Box or a "care-of" address. I'd be interested in the views of others on this point, but it strikes me that there could be privacy-related concerns about trying to identify home locations of library patrons.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/132#issuecomment-436920751, or mute the thread https://github.com/notifications/unsubscribe-auth/Apzywgc8bTzUFOWBozpvSNeobd6rt1c5ks5us_J_gaJpZM4YSgHS .

[franciscave]

Thanks for this further clarification regarding "home" locations. I think I now have enough information to be able to discuss your suggestions with my colleagues on the LCF Technical Panel, which meets tomorrow, and will provide a definite response after that.

[franciscave]

This issue was discussed at last week's LCF Technical Panel meeting. We came to the following provisional conclusions:

1. We propose to add a new element to LCF v1.0.2 to enable a Location to be marked as being a possible pick-up location. Details to follow in due course.
2. A Patron record can already have an associated Location of type 'Patron's "home" institution/branch/site/department'. If there is a need to identify a different Location as the Patron's preferred pick-up location, we can add a new association type 'Patron's preferred pick-up location' to code list LAT. Please could you confirm that this is what you require? I presume that if the Patron's preferred pick-up location isn't specified but the Patron's "home" institution is specified, the latter is assumed to be their preferred pick-up location.
3. Our current position is that LCF doesn't need to and indeed should not communicate information that the LMS has determined should be hidden from the terminal user. LCF is (currently, at least) a communication format and not an LMS data model. We would fully expect that an LMS would need to store information about LCF entities that would need to be withheld from terminal users unless they have the necessary privileges to retrieve the information. Thus, the permanent location of a Manifestation or Item might never be communicated, but the terminal user doesn't need to be told that the information is hidden from them.

[dkarvel]

Hi Francis, Thank you for the detailed response again.

1. Great : I look forward to receiving more information on the "Location to be marked as being a possible pick-up location"

2. Our need is to have a "Location to be marked as a possible patron's preferred location" This is not a patrons property. It is a Location property which will be used to retrieve /filter all locations a patron can choose from when they create their new patron record. So, to simplify the scenario: A new patron uses our web application to register for the first time. They are presented with a form of fields (personal, contact etc) as well as a list of Locations that he can choose one of them as their Preferred location. So, how will we select all the possible "preferred" locations? The list of locations must be retrieved from the LMS based on criteria such as "Location marked as a possible Preferred location".

3. Hidden locations are not shown to end users but they are shown to the library staff. Therefore a Staff application must see a hidden location in order to UnHide it from today. My understanding is that this is a Library Communications Framework and the expectation is to be adapted from LMS providers to provide data to the library apps or to 3rd parties e.g. RFID This is not very important as we can use a custom flag. However, this way we are running into the danger of each LMS and provider "extend" the LCF to their needs and become incompatible with each other similar to the SIP2 with so many custom extensions

I will be happy to be involved if required.

Thank you again, Dimitris

On Tue, 13 Nov 2018 at 02:08, Francis Cave notifications@github.com wrote:

This issue was discussed at last week's LCF Technical Panel meeting. We came to the following provisional conclusions:

1. We propose to add a new element to LCF v1.0.2 to enable a Location to be marked as being a possible pick-up location. Details to follow in due course.
2. A Patron record can already have an associated Location of type 'Patron's "home" institution/branch/site/department'. If there is a need to identify a different Location as the Patron's preferred pick-up location, we can add a new association type 'Patron's preferred pick-up location' to code list LAT. Please could you confirm that this is what you require? I presume that if the Patron's preferred pick-up location isn't specified but the Patron's "home" institution is specified, the latter is assumed to be their preferred pick-up location.
3. Our current position is that LCF doesn't need to and indeed should not communicate information that the LMS has determined should be hidden from the terminal user. LCF is (currently, at least) a communication format and not an LMS data model. We would fully expect that an LMS would need to store information about LCF entities that would need to be withheld from terminal users unless they have the necessary privileges to retrieve the information. Thus, the permanent location of a Manifestation or Item might never be communicated, but the terminal user doesn't need to be told that the information is hidden from them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/132#issuecomment-437915066, or mute the thread https://github.com/notifications/unsubscribe-auth/ApzywoR6HhWHmbBmqVaKP7h8qlJSzLrnks5uuY7ugaJpZM4YSgHS .

[franciscave]

Re point 2, why is this not answered by our proposed solution to point 1? When a patron registers, they can be presented with a list of all possible pick-up locations and choose one of them. I don't understand the concept of a "preferred pick-up location" without reference to a specific patron. Each possible pick-up location is conceivably the preferred pick-up location for one or more patrons. Why do you need to distinguish between "possible" and "preferred" pick-up locations? Is it that the library wishes patrons to choose a preferred pick-up location from a subset of all possible pick-up locations, and only to offer/use other pick-up locations in special circumstances?

Re point 3, it is not necessary for the LMS to communicate all information about a manifestation or item to all terminal users. This can be filtered based upon user type (e.g. patron or staff), which is something that presumably the LMS will keep track of during communication sessions. So, if a patron requests information about an item, and the location of that item is to be hidden from patrons (but not from staff), the location information is simply excluded from the response to the patron. If a member of staff were to make the same request, the location information would be included. I agree that the LMS needs to keep track of whether the location of an item is to be hidden from patrons or not, but that information would never need to be communicated in LCF, so I believe that this is a requirement on the LMS data model but not on the LCF information model, which is only concerned with what needs to be communicated to the terminal user.

What purpose is served by telling a terminal application (e.g. RFID scanner) that the location of an item is hidden? If the information isn't communicated to the terminal application, the terminal application could simply indicate to the user that the information is not available. This would not distinguish between "hidden" and "not known/recorded", but does that matter?

[franciscave]

Re point 3 again, are you wanting user access to information to be controlled by the terminal application and not by the LMS? I have made the assumption that it is the LMS that determines what information to include in the response, based upon the identity of the terminal application and the identity of the human user. Are you delegating part of the LMS's responsibility for user access management to the terminal application?

[dkarvel]

Hi Francis, Re point 2 : Correct. Two libraries (City of Sydney and City Of Melbourne) for example have over 10 branches however they are trialing 3 of them as pickup locations depot unmanned( on the train/subway waiting platform / ) and those locations are not allowed to be in the list of a user's "Preferred" home location where usually will go to pay their fees, be notified about events at that branch etc...

Re point 3 : Correct. It seems that the LMS can work that out in a different way the application will always know if it is an library operator or a patron requesting. No worries about this one. Please ignore it.

Thank you again Francis, Dimitris Karvelis

On Wed, 14 Nov 2018 at 01:43, Francis Cave notifications@github.com wrote:

Re point 2, why is this not answered by our proposed solution to point 1? When a patron registers, they can be presented with a list of all possible pick-up locations and choose one of them. I don't understand the concept of a "preferred pick-up location" without reference to a specific patron. Each possible pick-up location is conceivably the preferred pick-up location for one or more patrons. Why do you need to distinguish between "possible" and "preferred" pick-up locations? Is it that the library wishes patrons to choose a preferred pick-up location from a subset of all possible pick-up locations, and only to offer/use other pick-up locations in special circumstances?

Re point 3, it is not necessary for the LMS to communicate all information about a manifestation or item to all terminal users. This can be filtered based upon user type (e.g. patron or staff), which is something that presumably the LMS will keep track of during communication sessions. So, if a patron requests information about an item, and the location of that item is to be hidden from patrons (but not from staff), the location information is simply excluded from the response to the patron. If a member of staff were to make the same request, the location information would be included. I agree that the LMS needs to keep track of whether the location of an item is to be hidden from patrons or not, but that information would never need to be communicated in LCF, so I believe that this is a requirement on the LMS data model but not on the LCF information model, which is only concerned with what needs to be communicated to the terminal user.

What purpose is served by telling a terminal application (e.g. RFID scanner) that the location of an item is hidden? If the information isn't communicated to the terminal application, the terminal application could simply indicate to the user that the information is not available. This would not distinguish between "hidden" and "not known/recorded", but does that matter?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/132#issuecomment-438290478, or mute the thread https://github.com/notifications/unsubscribe-auth/ApzywgCv_IKMwZAcBDqiEO-F0jNezEjFks5uutqogaJpZM4YSgHS .

[franciscave]

Good, I think this is now clear.

We already have the ability to associate a patron with a "home location", as I indicated in my initial response (E03C03 Associated location with E03D03.1 Association type containing code value LAT03). We could perhaps be a bit more clear that this is distinct from the patron's "home institution" (E03D34 Patron's home institution), which associates a patron with an authority/institution as a legal entity rather than as a physical location.

A library may wish to offer new patrons the ability to specify their normal pick-up location to be different from their home location.

It seems to me that we therefore need to modify both the Location entity and code list LAT Location association type, and add one or two more code lists.

Location entity

The Location entity needs to be modified so that it can indicate whether the Location is any of the following:

• A possible patron home location
• A possible patron preferred pick-up location
• A possible pick-up location, but not a possible patron preferred pick-up location.

While the latter two of these are mutually exclusive, it should be possible to specify a patron's home location independently of whether or not it is a patron's preferred pick-up location. As discussed during the Technical Panel meeting, there are two possible approaches:

• Add a single new element 'Location property' and allow it to be repeatable with different code values for each of the above "properties", with indications that certain code values are mutually exclusive. In this case only a single code list would be need to be added. Or, alternatively:
• Add two new elements:
  • 'Possible patron home location', which would take one of two code values '00' for 'Not selectable as a patron home location' and '01' for 'Selectable as a patron home location' from a new code list LOH;
  • 'Possible pick-up location', which would take one of three code values '00' for 'Not a possible pick-up location', '01' for 'A possible pick-up location, but not selectable as a patron preferred pick-up location' and '03' for 'A possible patron preferred pick-up location' from a new code list LOP.

I favour the latter approach, as it would allow for greater extensibility in future, by adding more nuanced code values to the new lists LOH and LOP.

Location association type

We already have LAT03 for 'Patron's home location'. We need just one further code value for 'Patron's preferred pick-up location'.

[franciscave]

I may be wrong about one thing: that a patron might be allowed to select their home location. If this is not selectable in practice, we don't need to add a 'Possible patron home location' element.

[dkarvel]

Thanks Francis, I also favour the second approach of adding the two new properties.

Thank you

On Wed, 14 Nov 2018 at 03:18, Francis Cave notifications@github.com wrote:

Good, I think this is now clear.

We already have the ability to associate a patron with a "home location", as I indicated in my initial response (E03C03 Associated location with E03D03.1 Association type containing code value LAT03). We could perhaps be a bit more clear that this is distinct from the patron's "home institution" (E03D34 Patron's home institution), which associates a patron with an authority/institution as a legal entity rather than as a physical location.

A library may wish to offer new patrons the ability to specify their normal pick-up location to be different from their home location.

It seems to me that we therefore need to modify both the Location entity and code list LAT Location association type, and add one or two more code lists.

Location entity

The Location entity needs to be modified so that it can indicate whether the Location is any of the following:

• A possible patron home location
• A possible patron preferred pick-up location
• A possible pick-up location, but not a possible patron preferred pick-up location.

While the latter two of these are mutually exclusive, it should be possible to specify a patron's home location independently of whether or not it is a patron's preferred pick-up location. As discussed during the Technical Panel meeting, there are two possible approaches:

• Add a single new element 'Location property' and allow it to be repeatable with different code values for each of the above "properties", with indications that certain code values are mutually exclusive. In this case only a single code list would be need to be added. Or, alternatively:
• Add two new elements:
  • 'Possible patron home location', which would take one of two code values '00' for 'Not selectable as a patron home location' and '01' for 'Selectable as a patron home location' from a new code list LOH;
  • 'Possible pick-up location', which would take one of three code values '00' for 'Not a possible pick-up location', '01' for 'A possible pick-up location, but not selectable as a patron preferred pick-up location' and '03' for 'A possible patron preferred pick-up location' from a new code list LOP.

I favour the latter approach, as it would allow for greater extensibility in future, by adding more nuanced code values to the new lists LOH and LOP.

Location association type

We already have LAT03 for 'Patron's home location'. We need just one further code value for 'Patron's preferred pick-up location'.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/132#issuecomment-438328135, or mute the thread https://github.com/notifications/unsubscribe-auth/Apzywgwpmpcv7OjChBe6DZ88OYGc3Pzlks5uuvDVgaJpZM4YSgHS .

[dkarvel]

Aurora LMS allows the patrons to choose their "Home" location. This can be the branch closest to home address or to work address or even a branch that is not allowed to be a pickup location due to stock has been removed temporarily.

I believe what LCF must do is define those properties and their definition. If LMS or 3rd parties want to go beyond they can either ask for adding new ones as long as they can define them. So, maybe its a good idea if LCF defines the terminology "Home" or "Preferred" or "CollectionPoint" or "Virtual" or "Depot" or "temporarydropoff" (train stations can have a locked unmanned returns box) or "Loans dispenser"

etc...

Thank you, Dim

On Wed, 14 Nov 2018 at 03:21, Francis Cave notifications@github.com wrote:

I may be wrong about one thing: that a patron might be allowed to select their home location. If this is not selectable in practice, we don't need to add a 'Possible patron home location' element.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bic-org-uk/bic-lcf/issues/132#issuecomment-438330865, or mute the thread https://github.com/notifications/unsubscribe-auth/ApzywrD3I3NA88G79m369k3Rf5HiXdFGks5uuvGBgaJpZM4YSgHS .

[franciscave]

I agree that we need good definitions of terminology.

Having read the actions from last week's Technical Panel meeting, I see that we came up with the name 'Location purpose' for a single generic element, which could be repeatable. I'll reconsider this possibility in the light of the above list of Location purposes.

[franciscave]

To add "location purpose" to the Data Framework we would need something like the following:

Id	Element	SIP2 ID	Card.	Format	Description
...
E04D04	Location type		0-1	Code	LCF code list LOT
E04D09	Location purpose		0-n	Code	LCF code list LOP Added in v1.2.0
E04D05	Location description		0-1	String
...

The changes to the XML binding would need to be something like:

	Element ID	XML structure	Card.	Data type	Notes
...
8	E04D04	location-type	0-1	Code	LOT
9	E04D09	location-purpose	0-n	Code	LOP Added in v1.2.0
10	E04D05	description	0-1	string
...

The new code list LOP would need to be something like:

LOP Location purpose (Added in v1.0.2)

Code ID	Code value	Definition	Notes
LOP01	01	May be selected by a patron as their home location
LOP02	02	May be selected by a patron as a preferred collection point
LOP03	03	A collection point, but not selectable as preferred
LOP04	04	A return/drop-off point

What other codes are needed? I don't understand "virtual" in this context - it isn't a purpose. How does "loans dispenser" differ from other collection points?

What about hidden locations, which are mentioned in the original issue posting? I think this is a different issue. Any location might be marked as to be hidden, i.e. not disclosed, but if it is never disclosed, we don't need to have a mechanism in LCF for indicating that. We only need such a mechanism if under certain circumstances a hidden location can be disclosed, e.g. dependent upon the identity of the terminal application or the user. The requirement needs to be spelled out more clearly.

[mdovey]

Tech Panel on 11/6/2019 agreed documentation changed.

Further information needed from @dkarvel as regards hidden locations.

[mdovey]

The first two issues have been addressed in 1.2.0.

The remaining issue concerns hidden locations for which a new issue has been created for discussion post 1.2.0 - see issue #240