ONIX-PL Webinar Q&A

Below are listed questions that were submitted during the NISO webinar, ONIX for Publications Licenses (ONIX-PL): Simplifying License Expression. Not all the questions could be responded to during the live webinar, so those that could not be addressed at the time are also included below.

Speakers from this event included: Alicia Wise (Chief Executive , Publishers Licensing Society and Chair, NISO ONIX-PL Working Group), Rick Burke (Executive Director, The Statewide California Electronic Library Consortium), and Jeff Aipperspach (Senior Product Manager, Serials Solutions). In addition, David Martin and Francis Cave (EDItEUR consultants) provided input to the event slides and discussion as well as contributed many of the answers below.

Feel free to contact us if you have any additional questions about library and technical services standards, standards development, or if you have have suggestions for new standards, recommended practices, or areas where NISO should be engaged.


ONIX for Publications Licenses (ONIX-PL): Simplifying License Expression
Webinar Questions and Answers
September 10, 2008


Question 1: Is there a discussion list devoted to ONIX-PL?

Answer (Alicia Wise): Great idea! We'll share this with EDItEUR as a suggestion for supporting implementation, and Karen Wetzel has indicated NISO has tools for supporting a more general discussion list. [Note: A discussion list is being formed; information will be up on the NISO website shortly -- this page will be updated once it is available.]


Question 2: What are the major differences (if any) between the DLF ERMI fields for licenses than ONIX PL?

Answer (EDItEUR): There are two main kinds of differences. One, ONIX-PL sets out to make it possible (though not obligatory) for everything in the licence to be captured, so it has terms that ERMI doesn't recognise. Second, while many ERMI terms have an exact ONIX-PL equivalent (e.g., Print Copy), ONIX expressions are built on a consistent generalised data analysis into which some ERMI terms don't fit directly in their present form. So some things that are in both ONIX and ERMI are expressed in a different way. A good example of this is the treatment of distance learning. ERMI treats distance learning rather as if it were a usage type, like Print Copy. The analysis that underpins ONIX-PL says that distance learning isn't a usage type-it's an extension of the set of Authorized Users to include students on distance-learning courses as well as students based on campus. Those distance-learning students will then have the same usage permissions and prohibitions as other Authorized Users. So ONIX-PL handles distance learning through the definition of Authorized Users.


Question 3: Rick, do you find the DLF ERMI elements are sufficient to capture the ILL restriction terms across your various licenses?

Answer (Rick Burke): So far we have. I'm curious myself to see how any expansion of these terms by ONIX-PL will impact the current DLF ERMI environment.


Question 4: The speakers only specifically have mentioned books/serial publishers-will this work with database licenses?

Answer (Alicia Wise): Yes.


Question 5: ONIX-PL as currently proposed is a supplement to the license and not a replacement for the license itself, and would require continued review of the actual license. Is there a possibility of using the ONIX terms as the license itself?

Answer (Rick Burke): The ONIX terms are a framework for expressing the license terms themselves and would not replace the license itself. Instead, it's a tool to streamline and organize the license into its various terms and conditions. So, review would still be required.


Question 6: Do you see a move towards dropping text licenses altogether, and just having sets of negotiated, coded terms of use that could serve as the agreement between publishers and libraries?

Answer (EDItEUR): We aren't suggesting this -but, interestingly, in a recent conversation with a UK intellectual property lawyer well known in the publishing industry, he not only suggested it, but seemed to be quite keen on the idea! But if it happens, it'll certainly take time….
Answer (NISO): SERU: A Shared E-Resource Understanding (NISO Recommended Practice RP-7-2008) is an example of a move in this direction. As stated in the introduction to SERU, "SERU offers publishers and libraries the opportunity to save both the time and the costs associated with a negotiated and signed license agreement by agreeing to operate within a framework of shared understanding and good faith. The statements below provide a set of common understandings for publishers and libraries to reference as an alternative to a formal license when conducting business." More information on SERU can be found at www.niso.org/workrooms/seru/.


Question 7: Will you be also working on the XSLT if one needs to import/export activity?!

Answer (EDItEUR): The ONIX-PL editing tool, OPLE, makes extensive use of XSLT and, as you would expect, already has the capability of importing and exporting license expressions in ONIX-PL format. However, the questioner may be more concerned about import and export of license data held in other XML formats in existing systems. This is probably a question for the system vendors responsible for such formats.


Question 8: Does ONIX support schedules, appendices, and similar documents that come as part of a license?

Answer (EDItEUR): Up to a point. In our view, schedules that provide lists of licensed resources and related pricing constructions are-at least for the time being, and perhaps permanently-best kept out of the licence expression as such. They can be referenced from the expression, but not carried as part of it. However, insofar as they affect permissions and prohibitions, they would be taken into account. And the ONIX-PL expression can carry links to any number of different documents (e.g., successive licence amendments) that combine to represent the latest status quo.


Question 9: What is the difference between the data dictionary schema and the ONIX-PL schema not yet released?

Answer (EDItEUR): The best way of looking at this is to consider that the ONIX-PL schema is in two parts. One part (.xsd file) defines the XML structure. The other part (also a .xsd file) carries Dictionary entries for all data elements that require controlled values. Both parts must be used together to define the XML format. The schema could just as well be delivered as a single file, but the advantage of doing it this way is that Dictionary updates can and will be issued whenever needed without affecting the structure definition. Moreover, the structure has been generalised in such a way that new functionality can most often be added simply by adding new Dictionary values, rather than having to add new elements to the structure. For example, if we wanted to add the ability to carry notes about a clause that has been amended, as suggested in the response to Question 13, that would simply mean adding a new value for the element "Annotation Type". So we hope that the structure will remain pretty stable, as it has so far during testing, but there will certainly be quite frequent updates to the Dictionary as new requirements are identified and encoded.


Question 10: Do current ERMs contain the necessary code or applications to enable them to read the XML documents?

Answer (Rick Burke): Not yet that I am aware of; this is what Serials Solutions is currently working one.


Question 11: Does ONIX-PL allow for system-to-system transfer of information for multiple libraries at one time? If so, how are the libraries identified (e.g., OCLC or DOCLINE identifier, etc.)?

Answer (EDItEUR): An ONIX-PL message can carry one or many licence expressions, which could indeed be for multiple libraries; but clearly the systems in question would need suitable export/import processes. The message format allows senders and addressees to be identified by an ID as well as by name. Similarly, the licence expression format allows the licensors and licensees to be identified by an ID. In all cases, there is complete flexibility in the choice of an identification scheme, so either of the suggested schemes could be used. Again, adding a different scheme is a question of adding a new value to the Dictionary for an "identifier type" element.


Question 12: How is customized or negotiated license information added?

Answer (EDItEUR): We can only answer in terms of our ONIX-PL editing tool, OPLE. In time, we'd hope that system suppliers would offer other solutions for particular user communities. OPLE distinguishes between "templates" and "licences". A template is the ONIX-PL expression of a generic licence, and would usually be the starting point. The OPLE user would derive an "empty" licence expression, would add the details specific to the individual licence, and would enter any negotiated variations from the template-much the same as would happen with the paper licence.


Question 13: It sounds as if publishers will be able to provide librarians with their generic license via ONIX-PL as a starting point for negotiation of specific terms & rights for an individual institution. The final negotiated license could then be loaded into a particular library's ERM. Will ONIX-PL be able to show how the final negotiated license differs from a given publisher's generic license? This would be useful in future negotiations with the publisher, to remind librarians of which terms had to be changed.

Answer (EDItEUR): ONIX-PL has been designed to express the content of a license, not explicitly to express the difference between two drafts of a license. However, there is provision to add annotations to the expression at almost any level, and, if users want it, we could define an annotation type for "variation from original text" to be used to carry a note, probably including the original text, when a variation has been negotiated. There may also be other methods by which such variations could be managed in a more structured way. In principle a tool such as OPLE could be enhanced to highlight the differences between two license expressions, but this facility isn't being developed as part of OPLE Version 1.0. A number of existing XML tools can be used to compare XML expressions and highlight the differences between them, and we would anticipate that the integration of such tools into an ONIX-PL viewing and editing system (whether based on OPLE or not) will be part of the value that system vendors can add to existing tools.


Question 14: We're seeing a lot of "revised" licenses coming through now, and the publisher is just changing a section or two. As far as functionality, can you load just sections of a license so you can in essence "protect" interpretations you have already made on sections not being revised?

Answer (EDItEUR): This is possibly a question to be addressed in the design of the processes by which an ONIX-PL expression is loaded into an ERM system. If there proves to be a way in which an enhancement of the ONIX-PL format could make it easier, of course we would pursue it.


Question 15: If an agent interprets the licence into ONIX-PL, who is liable for errors or misinterpretations in the coding process?

Answer (EDItEUR): ONIX-PL allows (but does not as it stands require) the responsibility for the licence expression to be explicitly stated at various levels-for the expression as a whole, for individual terms and definitions, and even for individual annotations. That means there's a mechanism for recording responsibility if people choose to use it. Not exactly an answer to the question-it probably needs to be put to the agents themselves.


Question 16: Since both the publisher and the library can enter the license information, are there mechanisms for resolving discrepancies in the interpretation of the terms?

Answer (EDItEUR): It's difficult to see quite how there could be "mechanisms" in the format itself for "resolving" discrepancies, but ONIX-PL is a format for communicating licence expressions, and that communication can be in both directions. As far as identifying discrepancies is concerned, see comments on comparing two licence expressions in the response to Question 13.


Question 17: What issues are there with reflecting ambiguous licensing terms using ONIX?

Answer (EDItEUR): The ONIX-PL Dictionary allows terms to carry a status "Interpreted as permitted" or "Interpreted as prohibited", just as ERMI does.


Question 18: What is the current interest/commitment by vendors and subscription agents in providing ONIX-PL interpretations?

Answer (Rick Burke): EBSCO is interested in doing this and has loaded the full text of many licenses into their system. I believe Swets is looking at this as well. As for ONIX PL, I'm not sure of their commitment at this time, but I suspect EBSCO is quite interested in working with this.


Question 19: Which ERM vendors besides Serials Solutions are involved in piloting ONIX-PL?

Answer (Rick Burke): None that I am aware of currently, but I can't speak authoritatively on this.
Answer (EDItEUR): We are in touch with (we believe) all the existing, and one or two prospective, ERM vendors; but for obvious reasons we aren't in a position to speak for them on how far their plans may have gone.


Question 20: Has ONIX-PL been tested with Innovative Interfaces or any other ILS ERMs?

Answer (Rick Burke): Not that I'm aware of; most likely you'd have to ask III.


Question 21: Could you provide a list of all content providers/publishers who are planning to make their licenses available in ONIX-PL format by the end of this year? Any who plan to implement in 2009?

Answer (EDItEUR): It's early days yet. It would be unreasonable to expect any content providers to reach that stage in 2008. 2009 will be the year in which we hope there will be serious take-up.


Question 22:
When might we see a license from Springer or Nature or other publisher who is piloting ONIX-PL? What timeframe?

Answer (EDItEUR): We are in the process of preparing a number of examples to be released with the Version 1.0 documentation in the next month or two. We are seeking the necessary permissions from publishers whose generic licences have been mapped-we can't yet say for sure whose will be in the package.