Packages are a way of grouping TIPPs or multiple packages together. They represent a set of content which may be governed by a single set of terms (licence or other T&C) over a period of time.
Packages are really a way of splitting sets on content into groups with some level of shared characteristics or data that it is useful to be able to act on at a single time.
For example, one might add a package to a subscription; or update all journals in a package at the same time with some new data.
Perhaps the simplest example of a package is JSTOR Arts and Sciences I (http://about.jstor.org/content-collections/journals/arts-sciences-i) – this is a package that can be defined at an global level, and all those subscribing to ‘JSTOR Arts and Sciences I’ get access to the same content. If a new title, or new coverage is added to ‘JSTOR Arts and Sciences I’ all those subscribing get the new content. I’m going to call this an ‘globally consistent’ package.
Some packages are negotiated on behalf of a consortia, or group of potential subscribers. There are different kinds of consortial package:
- The ‘consortially consistent’ package – similar to the globally consistent package – everyone in the consortia gets access to the same content.
- The ‘consortially variant’ package – where although the package is offered to the consortia, what content an institution gets access to varies between institutions
The ‘consortial variant’ packages may vary in the titles that an institution gets access to (not all institutions get access to the same titles) and/or vary in the coverage of the titles (different years/issues).
Institutions may also negotiate access to sets of content for themselves. These could be seen as ‘packages’ in the KBPlus sense, although institutions are more likely to think of them as individual titles. Our current approach in KBPlus is to say these should be handled by creating a subscription to the Master package and then expressing specific local access through Issue Entitlements. In some ways we could regard the Master package as a Globally Variant package – i.e. one to which is offered globally but within which each institution gets access to different content.
So – in summary 4 types of package:
- Globally consistent – e.g. JSTOR Arts and Sciences I
- Globally variant – e.g. the Master list of all titles and coverage in a publishers front file
- Consortially consistent – e.g. SHEDL OUP Collection (I think?)
- Consortially variant – e.g. NESLi2 Nature Package
I suspect that all of these are useful grouping of content.
It may be some ‘packages’ are actually made up of several sub-packages of these types. For example maybe we can identify a consortial package, where one part (a limited list of titles) is consortially consistent, while other parts of the same package are consortially variant. This could simply be seen as a consortially variant package, but it may make sense in KB+ to treat it as two packages belonging to a larger package – thus gaining benefit of managing the consortially consistent parts at a consortial level?
Because packages are essentially just ways of grouping TIPPs and other Packages it is sometimes difficult to decide where a package ends – especially in the case of consortially variant packages. Deciding how you represent different combinations in KBPlus can be difficult, partly because KBPlus provides a lot of flexibility. For example if we take an institutional subscription to a range of Wiley titles, some of which are part of a consortial deal, and some of which are additional titles that the institutions subscribes to separately. This situation could be modelled in a few ways:
- One package (consortially variant – the extra titles are treated as just part of the variation), one subscription, one licence
- Two packages (one consortially variant, one globally variant – the extra titles are picked from the Master list), grouped as a subscription package, one subscription, one licence
- Two packages (one consortially variant, one globally variant – the extra titles are picked from the Master list), two subscriptions, one licence
- Two packages (one consortially variant, one globally variant – the extra titles are picked from the Master list), two subscriptions, two licences
While the package entity is pretty flexible, the subscription and licence entities are more restrictive, as they have specific properties which apply to all linked packages/issue entitlements. For the subscription:
- Start date
- End date
- Notice period
For the licence
- Key values
- Licence documents
So only where all the content in question shares these properties can they be linked to single subscriptions/licences.
Going back to the Wiley example above, it probably makes sense to model using (2), (3) or (4), with the decision being based on whether the content shares the subscription/licence properties.
Kings College London ‘Sage’ example
Another example was offered by Kings College London (KCL). In this example there was:
- Sage Premier Package negotiated via JISC Collections to which KCL has a subscription which runs January-December
- Sage Management and Organisation Studies package (http://www.sagepub.com/librarians/collections/mgmtorg.sp) to which KCL has a subscription which runs August-July
- Several individual titles from Sage to which KCL has subscriptions running January-December
In this case the fact that (b) runs for a different subscription period forces the use of three subscriptions, linked to three packages. It isn’t clear whether all three of (a), (b) and (c) are covered by the same licence. It seems likely that the Sage Premier package at least is governed by a specific licence.