Platforms, UX iteration 3, English

Video:

Prototype:

Nice to see updates to the Platform. I feel like we might be moving on some parallel tracks with regards to ERM, so want to make sure any discussions and changes to the prototype that are happening here are tied into the work happening with Owen Stephens @ostephens and the ERM subgroup.

Regarding terms of use on a platform: it seems like the appropriate place to store these terms would be with the License record and then they would get pulled to display on the Platform record? And if there are multiple licenses, with different terms, would each version be displaying (e.g., your journals on the platform can be ILLed, but the publisher prohibits ILL of full ebooks, but does allow for ILL of chapters–how would this displayed)?

I also feel like we are still struggling a bit with definitions: what is a platform? Within the ERM subgroup, we have talked about coming up with a glossary of terms and definitions to make sure we are all on the same page. Early on, the Product Council developed a glossary from several previous projects, which is available here. Platform is defined as, “An interface that administers or delivers electronic resources content, or provides a route to the content, to the user. A single publisher may have multiple platforms, eg: Elsevier has Science Direct, Scopus, and Compendex/Engineering Village. The platforms of one publisher may or may not be integrated in one administrative site.” I believe Owen is planning to review terminology for ERM so that the ERM subgroup can come up with terms and makes sure the existing glossary is still fitting our current mental model.

In some cases it can be hard to tell what is a platform versus a package of content. ACM Digital Library, as used in this example, could be considered a platform where ACM delivers its content, but it is also a bundle of content licensed by ACM and sold to libraries. The terms and conditions of use tend to be assigned at the level of this licensed content. I am questioning whether it makes sense to connect Licenses directly to Platform, or to have this information flow through the Package/Resource/Agreement (whatever the name) record as being hashed out in the ERM group. I think a Platform record is absolutely needed for ERM, but as I view it as the inferface, it would not be the place where I would think to find terms of use.

Kristin’s thoughts on how license terms are related to platforms echo some of what I was thinking when I was watching the demo of the prototype. I was not sure what the intention was for how license terms would be displayed - would they be recorded in an associated license agreement and then inherited to the platform? And if so, as Kristin asks, would the terms for each agreement display? Or would some sort of manual summarization process be required?

Another question I had regarding associated license agreements is whether terms from all associated agreements would be displayed or just for active agreements (active agreements being more desirable for obvious reasons). For that matter, would there be a reason to display inactive or superceded licenses associated with a platform in this view? For major vendors that could be a really long list, even if only including active agreements (I’m thinking of ProQuest when we sign a new order form / agreement for every new 1x purchase).

It’s great to see the platform record in progress and off to a strong start! I shared some questions relating to licenses in reply to Kristin’s comment, but I had some separate questions that I wanted to add as well.

Similar to Kristin’s question about what we mean by platform, what do we mean by “vendor”?
In RM SIG I think we have been using “vendor” to mean the organization receiving payment for an order, but if we were to use that definition in platform, many of my platforms would have EBSCO or Harrassowitz as the vendor since we purchase resources through them so frequently, even if they are not the platform provider or “owner,” nor the publisher of the content. We may need multiple roles that organizations can have in relationship to a platform, and each platform should be able to be related to multiple organizations (a one to many relationship).

For example, I pay EBSCO for subscriptions to journals hosted by Project MUSE, which is the platform provider, but it hosts content published by dozens of different publishers. So we may want EBSCO linked as an agent, Project MUSE linked as a platform provider, and various publishers linked as publishers of the hosted content.

Alternatively, we may only want to express the relationship between the platform and the organization that provides or “owns” the platform (in the example above, just Project MUSE). Either way, we should be clear and consistent in our terminology when talking about these different roles that various organizations can have in relation to a platform.

In addition, I was hoping that Filip or someone from Chalmers could talk more about the intended use of the description, subject area, and type of content fields. The subject area and type of content fields look like tags - is that correct? What is the usefulness of tagging a platform with that information rather than at the level of a database or collection?

@VirginiaMartin, @kmarti

I think everyone agrees that logically, one would lean towards describing terms of use for a given license. In this particular iteration of the Platforms app, the starting point — and the reason we have even discussed the notion of a Platforms app and records in the Chalmers context — is that, at Chalmers, as a service to patrons, license terms are summarized for the full platform. In the existing setup for the institution, duplicate licenses are created in order to contain a shared summary of multiple other licenses, as I’ve understood, it, and this duplicate license (which is really a Terms of Use document for a platform) is then associated to a platform or database. Chalmers shows these terms of use in their list of databases. To me, it seems intuitive (for this use case!) to include the terms of use summary in the platform record itself. The linked licenses are merely there to show staff members how the summary in the Platform record came about, in this concept.

I think the point on agreeing on terminology is an important one, and it is as relevant in this discussion as in any other topic covered in FOLIO — discussions on library workflows is definitely not the place to be lax on terminology

Whichever terms you agree on in the RM SIG and associated groups, we should try to use as a project. I am not aware of an established FOLIO definition of Platform that does not lend itself to the use case above. In a descriptive sense of the word, platform seems like an appropriate term for what it is associated with here, to me, but I have no strong opinion on this matter.

@VirginiaMartin, your point on other terms used and how those are interlinked conceptually and technically with the rest of the system, is a good one. I do not think I am able to answer your questions on this, nor to make a sufficiently informed decision on the matters raised. I think the RM SIG and subgroups should decide on these things. I recommend you all get in touch with e.g. Chalmers to make sure that the needs they have as a beta library, are not prevented by looking only long term; nor seen as the definitive list of requirements for all libraries needing to use a Platforms app (no one is intending that these beta-requirements be used as such).

I put this same reply over on the license thread, but adding it here too:

I completely agree about the need to be able to distinguish different types of organizations. We need to ensure we’re using the same terms in the same way across acq, ERM, MARCcat, Inventory, etc: vendor (for the $$ relationship, unless folks can think of a better word), licensor, access provider, publisher.

One example might be Oxford eBooks, where a library might have the vendor as GOBI Library Solutions, the licensor and access provider is Oxford, and the publisher may be Oxford or may be a number of other UPs that Oxford hosts on their platform.

And within a single access provider, there may be multiple actual platforms that need to be distinguished - for example, perhaps separate platforms/interfaces for eBooks vs eJournals vs databases. Patrons don’t necessarily need to understand all these details and interrelationships as long as they can click a link and get to what they need, but these details seem critical for ERM and Acquisitions staff.

Thanks for your reply, Filip, as I think I your comment that I’ve quoted below hints at an approach by Chalmers to the Platforms app that RM SIG may want to discuss.

It sounds like Chalmers wants to use the Platforms app to run a database A-Z list, hence the description, subject area, and content type tags that I asked about in a previous comment. I would very much like to discuss in RM SIG (tagging @kmarti here to make sure she sees this!) whether we want to conflate Platforms and databases in this way, and if FOLIO’s Platform app should be designed around running a database A-Z list, which I do not think it should. Database A-Z list tools are great, but I think we can come up with a better way to run one in FOLIO than building it into the Platforms app. It seems to me that it would be better to have a separate app that could pull in data from other apps - possibly the Platforms app but also other apps/records that would allow us to pull in a single title (e.g., Nature) a collection or package (e.g., Ebooks on EBSChost), or an actual database (e.g. Academic Search Complete). In addition, this would allow the display of license terms at the level of the collection/title/database as appropriate, which is a more effective and efficient way to convey these terms to users since they won’t have to read through long summaries. Hopefully it would also be more efficient for library staff as those terms can be inherited directly from the associated license and not manually summarized by staff at the Platform level.

It sounds like Chalmers as a beta site needs to have this functionality somewhere, so perhaps the Platforms app is the place to put it for now for them. However, it doesn’t seem like the best option going forward “in the long term” as it won’t accommodate all use cases for a database A-Z list that a dedicated app would.

@Ann-Marie, We were looking over some of the requirements from Kuali OLE, and we did have tie-ins between the vendor and these other roles you mention for organizations. In fact, originally we had simply called it “organization” and instead of creating a new record type, decided to reuse the vendor record. Ultimately, we ended up making a “non-paying vendor” checkbox, and lumping the other types of roles into that category, but this freed up the need to fill in fields that were specific to payment. This would have allowed the vendor record to be synced up to the Organization record from GOKb. So there could very well a vendor record connection to the eHoldings app.

@filipjakobsen, I guess when I consider licenses and platforms, the license is usually with a specific organization, and the terms of use cover a package of content that is available on a platform. So in my mind, I had been associating the terms of use with a particular package from a particular vendor, not with the platform, which I consider more of the delivery mechanism. For example, if I purchase a bunch of collections from Alexander Street, I would associate the license with each particular Alexander Street Collection, not with the platform (search.alexanderstreet.com). However, it wouldn’t necessarily be wrong to associate the license with the Platform, so maybe in thinking about our model, we can provide flexibility to associate a license with a Platform, Vendor, or particular package. A lot of providers negotiate a master license, and then will add specific terms as needed for individual content packages. For Alexander Street, now owned by ProQuest, that content could be covered by ProQuest’s master license, which would also apply to a number of other platforms developed and managed by ProQuest, though specific terms might also apply just to certain bundles of content.

@VirginiaMartin, I think you are correct about the desire create a Databases A-Z list, as well as some terminology confusion between Platform vs. Database. In some cases, a database can be the same as a platform, but there are many cases where a database is a discrete bundle of content that resides on a Platform. I’ve been having a concurrent Slack conversation to learn more about the needs and invite them to the RM SIG. Chalmers will be at WOLFcon and they should be able to come to the RM SIG meeting on May 4.

With regard to the Chalmers use case, associating a license with a platform:

We do something similar at Cornell with our own Terms of Use functionality (based off Intota ERM data) in which a license is associated with a Provider, and cascades down to a package/title level unless overridden. Intota doesn’t really have a “platform” analogue, so it’s not quite the same.

But what I’m aiming at is: in our experience, attaching a license to the top level (be it Provider or Platform) is often appropriate because many platforms do use the same license for all their content, but for those platforms that don’t, it’s usually just a “good enough” shortcut, because we don’t have the time or tools to be really accurate about it on a more detailed level.

For example, all our EBSCOhost perpetual-access ebooks are considered to be in the same package, but we have multiple licenses associated with that collection, because the simultaneous user limit varies by title. Intota allows you to attach a different license to each ebook - but it doesn’t allow you to do it in a batch process. We are so not clicking through the license change checkboxes one-by-one for thousands of ebooks, so instead we would attach the single-user license to the whole package and call that good enough for now (which is likely to turn into forever, as we all know). It’s the easiest, safest choice - but it’s not accurate in the way we really need it to be.

The other thing I’d note is that, by writing a summary of the license terms into the platform record, we would be duplicating data and risking conflicting information. If the agreement changes, and we update the license record but forget to update the platform record, the platform record will be wrong. So: if we need a summary of the license displayed on a different type of record, I think it should be auto-generated from the data that’s held in the official license record that’s attached.