Referencing digital materials rather than physical

[mdovey]

the current LCF model assumes physical format items, so it is not clear how to reference digital\online materials - for instance there is no current field for a URI\URL to the digital object.

One mechanism would be to wrap the URI\URL in a Location entity in field E04D03, and add a new entry to the LOT (Location Type) code list for URI\URL.

However, this may also need new entries in the LAT (Location Association) code list to be used when referencing such a Location from a Item entity (particularly if the LMS has both physical and digital versions of the object in question).

[franciscave]

The media type, i.e. the physical or digital format, of an item, is specified in the associated Manifestation entity in E03C03 (element media-type in the XML binding). Combinations of codes from ONIX code lists 150 and 175 should cover most needs, e.g. 'ED' (Digital download) from list 150 and 'E101' (EPUB) from list 175.

We need to think carefully about the location associated with a digital Item. The URI for downloading a digital Item may be specific to a Loan, rather than the Item, so should more properly be stored in a Loan entity, where we don't currently have an Associated Location property. On the other hand, an Item might always be downloaded from the same URI, and in any case the location of the server from which the Item is to be downloaded will probably not change too frequently. So, I agree that we probably do need new codes in list LAT (Location Association) and here are some candidates:

• Permanent URI of the Item on a Library server
• Permanent URI of an external server from which the Item may be downloaded
• Permanent URI of the Item on an external server (accessible only to Library systems)
• Loan-specific URI of an Item for download by the Patron

The last of these would only be used by an Associated Location property which would need to be added to the Loan entity.

I agree that we would in any case need to add a new code to list LOT (Location Type), but I also suggest that, rather than use E04D03 Location Name for the URI, it would be more sensible to use E04C02 Additional Identifier and add a code to list LOI (Location Identification Scheme) for 'URI'. E04D03 was designed for informal names as strings, not to carry identifiers.

[franciscave]

Regarding the code to be added to LOT (Location Type), a code meaning 'Virtual location' would probably be appropriate. This would allow for various ways of specifying the location, including URI and DOI, which would be specified by the appropriate code from LOI (Location Identification Scheme).

[mdovey]

On reflection, it may make more sense to be in the Loan entity (not least of all for the FASTEN use case)

Regardless of whether the URI is static or dynamic, if LCF is in use it may be safe to assume that a checkout is required to access the content.

If not checkout is required (which would be the case handled by placing it in the Item), it isn't clear why LCF is being used (since LCF is not a discovery protocol).

[franciscave]

This was discussed during the Technical Panel meeting earlier today. My impression (I was participating by phone) was that several Panel members felt that a temporary URI would not need to be persisted in the LMS, so would not need to be stored in a Loan record. The Panel need to review Matthew's most recent FASTEN slides to understand the use case that prompted this issue.

[mdovey]

I can order stand that in some cases the URI would not be persistent, and hence not permanently stored by the LMS (so might not be present on subsequent retrieval of the loan record). However, the URI would still need to be returned to the user\patron during the checkout process. This might be out of band (e.g. via e-mail) but real time delivery would need to be supported.

The workflow for digital and physical is different in the respect that the patron would normally have the physical item in hand prior to performing the check out, whereas for digital they would only get the item after checkout.

Unless we say that LCF is not suitable for checking out digital items where the user expects access in realtime (via a URI) after checkout, we do need a means of transfering the URI to the user at checkout. If not in the Loan record, I suppose it could be an extra field in the lcf-check-in-response. However this seems a little inelegant, and would be specific to the webservice implementation only rather than the underlying model.

[franciscave]

To resolve this issue I have added the following to the LCF documentation:

A new code '04' is added to list LOI (Location identifier type), meaning 'URI'.

A new code '04' is added to list LOT (Location type), meaning 'Virtual/network location'.

The above satisfy the requirement, when it exists, to specify a persistent location of a digital resource.

For non-persistent locations, such as would be given to a patron on check-out but not stored for future use, I have added R11D06 'Digital content access link and key' to the checkout response. If you feel that the link and key need to be in separate elements, please comment.

[franciscave]

At today's Subgroup meeting it was agreed that I should make it possible to include a download URL in a Loan record. This would not necessarily be a persistent URL, but when the Loan record is retrieved, the LMS could generate (or request the external content provider to generate) a URL for downloading the loaned digital item. I have modified the Loan entity.

[mdovey]

This element may need to be repeatable - I will check the use case with the NISO FASTEN group

[mdovey]

Is the new field in the Loan entity meant to be used in addition to the new codes in LOI and LOT or instead of (making those additions redundant)?

[franciscave]

We could have added 'Associated Location' to the Loan entity and added a new code value 'Digital item access location' to code list LOT, to be used with LOI04 ('URI'). Arguably, it would have been more consistent to do it this way, rather than have the flat element E05D13. It would be wrong to do both - we haven't done that. I think you may be confusing E04 Location (where we added E04C08 'Associated Location') and E05 Loan (where we did not). I think it is OK just to add E05D13 as a simple data element, rather than complicate things by adding an 'Associated Location' composite. Does this make sense?

[mdovey]

OK, so the new codes listed below are for use in E04 location for a permanent URL. whilst E05D13 is for a generated URL:

A new code '04' is added to list LOI (Location identifier type), meaning 'URI'. A new code '04' is added to list LOT (Location type), meaning 'Virtual/network location'.

[franciscave]

Correct. Does this need further clarification?

[mdovey]

No, I just need to double check if E05D13 needs to be 0-n rather than 0-1

[mdovey]

This is from a draft to NCIP to make their electronicResource element repeatable - this is the same use case for making E05D13 0-n:

[The FASTEN] main real-world use case for this is a situation where the ILS is capable of playing a media file on its own instead of forwarding the user to the eContent vendor's website. The most elegant way to handle that possibility is for the eContent vendor to respond with two URLs: one is the URL that refers to an HTML page with the eContent vendor's own player, and the other is the "deep" URL that refers directly to the content.

However, clearly there needs to be a way to determine which URL is which. In NCIP the electronicResource element can contain either an ActualResource element or a ReferenceToResource element. So I propose the following:

Element ID	XML Structure	Card	Data Type
E05C13	access-link	0-n
E05D13.1	link-type	1	Code
E05D13.2	link	1	String

And a new Codelist with initial value say direct, indirect

[franciscave]

Makes sense to me. I have implemented this in the main specification, the XML binding and the code lists (new list LKT).