item.yml and Ebook records

[agentilb]

I wanted to work a bit on the model that describes the items, and for the time being this model can describe both physical or electronic item(s) attached to a record.

I guess it would be simpler for the migration if we have one model for the physical holdings and one for the electronic holdings. Do you agree? if yes, I can send you updated models.

[agentilb]

As per our discussion on Tuesday, I understand you prefer to keep one model for the items (either online or physical).

I wanted to provide more details on how we see this model to behave:

The entities that can apply to both physical or online items are:
_private_notes:
public_note:
description:
medium:
visible:

The properties that concern only physical items are:
barcode:
library:
location:

The properties that concern only online items are:

dois: EDIT: dois were decided to be on a document level
urls:
persistent_identifiers:
open_access: (new):

open_access:
    description: |-
      :MARC: 536__r 
      To indicate if the access to this document is open or not. 
    type: boolean

number_of_pages: should be at the record level, I've placed it here by mistake.

For any item, the mandatory fields are: medium: and visible:
-> A physical item should have in addition at least a barcode, a library and a location
-> An online item should have in addition either an URL, a DOI or a persistent identifier

[ntarocco]

Hi Anne, thank you!
We also have some notes on the migration repo, see here. Maybe to be merge this there since Items are not records in CDS (not valid of e-books)?

We had a quick discussion on our side and we might go for different schemas, given that we will have also ILL items for example... We are still thinking to the best solution.

For now, we have this: https://github.com/inveniosoftware/invenio-app-ils/blob/master/invenio_app_ils/schemas/items/item-v1.0.0.json

• item_pid
• document_pid, document: the reference to the document
• internal_location_pid, internal_location: the reference to the location of the item (the library for you)
• legacy_id
• legacy_library_id
• barcode
• shelf
• description
• circulation_restriction: in case we want to have some limits on how to circulate this item
• medium: one of "NOT_SPECIFIED", "ONLINE", "PAPER", "CDROM", "DVD", "VHS"
• status: one of "LOANABLE", "MISSING", "IN_BINDING", "SCANNING"
• circulation_status: a reference to the current circulation status (if on loan or not)

Checking your comments, it looks to me that:

• _private_notes: To be added
• public_note: What is the difference with description?
• visible: this will he handled at the level of access restrictions, this field won't be needed

For e-books, we still need to see, especially because they are part of the document record.
We will come back to you when we have decided if to split or not the items! :)

[agentilb]

Hi @ntarocco,

Thank you very much for your comment.
It looks to me that the model you have corresponds well to the one suggested for the physical items. So fine with me.
public_note: is indeed something not necessary, since we have already the description field. It would indeed be more useful for electronic items than for physical items.

I share your concerns for the electronic holdings: the idea was to move the electronic holdings information at the item level (url /doi). But indeed, the DOI needs also to stay in the main record, since this is an identifier of the document. It is probably not a good idea to duplicate the information.
On the other hand, having a separate information about electronic holdings (=what we acquire) avoids to store acquisition information in the main record: the idea was to link those electronic holdings to the corresponding acquisition information.
I will also think further how this should be handled in the best way.

[ntarocco]

@agentilb I am working on the ebook data model. Can I try to re-phrase what you were saying just above and you correct me if something is wrong?

ebook data model:

• _private_notes: description not visible to users
• description: description potentially visible to users
• medium: I don't think this exists for ebooks
• visible: handled through access restrictions
• open_access: boolean, true or false, ok
• dois, urls, persistent_identifiers: see below

I would like to model correctly these fields. If I understood correctly, DOI is at the level of the document and ebook do not have a DOI.
Why the field persistent_identifiers? Do ebooks have more PIDs? Or is it the document?
I was thinking that the only useful field for ebooks was in fact URLs.

[agentilb]

Hi @ntarocco ,

First of all, I would prefer to call this object: electronic item or similar, I would prefer to have a more generic naming since an electronic item could be attached to other types of documents, such as proceedings or standards.

The fields you mention are correct:
_private_notes: description not visible to users
description: description potentially visible to users
open_access: boolean, true or false

Indeed no need of "medium", and the visibility of the item will be managed with access rights, as you suggest.

Then the access to the item can be done in different ways, mainly via a DOI or via an URL (if we have the DOI, we use the DOI, if we don't have a DOI, we use the URL - we prefer DOI since this is persistent), in some rare cases we might have URN or HDL, and in this case they should be in the field: persistent identifier (this was inspired by the Inspire model).
So in principle, we should have either a DOI, a persistent identifier or a URL to describe the access to an electronic resource. Is it clearer for you? Would you prefer a different organisation for those information?

One more thing, when we discussed this with Ludmila we agreed that the DOI (and also the Persistent identifier) should also be stored at the document level since those are an identifier of the document. Does it make sense for you?