Question about library/publisher reporting
Hello FIM4L members!
How many of you get reports from publishers on usage stats for billing purposes (maybe by using the COUNTER-SUSHI standards)? Have any of you done anything different to get this kind of information into a SAML workflow? A small group is spinning up in the REFEDS Schema area that’s discussing the possibilities here, and while we have publishers on hand to describe the use case, I was wondering what this might look like from the library perspective.
Feedback and further information most welcome!
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com
Hi Heather,
there have been discussions to use SAML to transmit information (e.g. group membership) to publishers and then break the usage reports down by that information, which has been discussed before and would be possible by using extended COUNTER Master Reports, but that doesn't seem to be the goal? Is the intention to protect access to the usage reports by SAML? That would be possible for the administrative web sites, but I don't think that it would make sense for the COUNTER_SUSHI API since that would add a lot of complexity. I'm a member of the group that has written the COUNTER specification, and the intention was to keep this as simple a possible which is why a) only the methods listed in section 8.2 of the Code of Practice are permitted and b) the parameters are simply passed in the URL, including the authentication information.
Best regards, Bernd
On 16.07.20 17:37, Heather Flanagan wrote:
Hello FIM4L members!
How many of you get reports from publishers on usage stats for billing purposes (maybe by using the COUNTER-SUSHI standards)? Have any of you done anything different to get this kind of information into a SAML workflow? A small group is spinning up in the REFEDS Schema area that’s discussing the possibilities here, and while we have publishers on hand to describe the use case, I was wondering what this might look like from the library perspective.
Feedback and further information most welcome!
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
HI Bernd,
This would be very much like extending COUNTER. Authorization attributes are a different thing; the feedback from the group discussing this feels that authorization should be handled via an entitlement attribute, whereas this kind of reporting should be in something else.
I don’t know if the answer is to extend the API, or do something else. It would be good to get folks together to talk about the possibilities.
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com On Jul 16, 2020, 9:02 AM -0700, Bernd Oberknapp bo@ub.uni-freiburg.de, wrote:
Hi Heather,
there have been discussions to use SAML to transmit information (e.g. group membership) to publishers and then break the usage reports down by that information, which has been discussed before and would be possible by using extended COUNTER Master Reports, but that doesn't seem to be the goal? Is the intention to protect access to the usage reports by SAML? That would be possible for the administrative web sites, but I don't think that it would make sense for the COUNTER_SUSHI API since that would add a lot of complexity. I'm a member of the group that has written the COUNTER specification, and the intention was to keep this as simple a possible which is why a) only the methods listed in section 8.2 of the Code of Practice are permitted and b) the parameters are simply passed in the URL, including the authentication information.
Best regards, Bernd
On 16.07.20 17:37, Heather Flanagan wrote:
Hello FIM4L members!
How many of you get reports from publishers on usage stats for billing purposes (maybe by using the COUNTER-SUSHI standards)? Have any of you done anything different to get this kind of information into a SAML workflow? A small group is spinning up in the REFEDS Schema area that’s discussing the possibilities here, and while we have publishers on hand to describe the use case, I was wondering what this might look like from the library perspective.
Feedback and further information most welcome!
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
-- Bernd Oberknapp Gesamtleitung ReDI
Albert-Ludwigs-Universität Freiburg Universitätsbibliothek Platz der Universität 2 | Postfach 1629 D-79098 Freiburg | D-79016 Freiburg
Telefon: +49 761 203-3852 Telefax: +49 761 203-3987 E-Mail: bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Heather,
the COUNTER_SUSHI API usually is used for application to application communication, so I'm wondering why SAML should be considered for this case. Which libraries/consortia have suggested this and what is their use case?
Best regards, Bernd
On 16.07.20 18:31, Heather Flanagan wrote:
HI Bernd,
This would be very much like extending COUNTER. Authorization attributes are a different thing; the feedback from the group discussing this feels that authorization should be handled via an entitlement attribute, whereas this kind of reporting should be in something else.
I don’t know if the answer is to extend the API, or do something else. It would be good to get folks together to talk about the possibilities.
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com On Jul 16, 2020, 9:02 AM -0700, Bernd Oberknapp bo@ub.uni-freiburg.de, wrote:
Hi Heather,
there have been discussions to use SAML to transmit information (e.g. group membership) to publishers and then break the usage reports down by that information, which has been discussed before and would be possible by using extended COUNTER Master Reports, but that doesn't seem to be the goal? Is the intention to protect access to the usage reports by SAML? That would be possible for the administrative web sites, but I don't think that it would make sense for the COUNTER_SUSHI API since that would add a lot of complexity. I'm a member of the group that has written the COUNTER specification, and the intention was to keep this as simple a possible which is why a) only the methods listed in section 8.2 of the Code of Practice are permitted and b) the parameters are simply passed in the URL, including the authentication information.
Best regards, Bernd
On 16.07.20 17:37, Heather Flanagan wrote:
Hello FIM4L members!
How many of you get reports from publishers on usage stats for billing purposes (maybe by using the COUNTER-SUSHI standards)? Have any of you done anything different to get this kind of information into a SAML workflow? A small group is spinning up in the REFEDS Schema area that’s discussing the possibilities here, and while we have publishers on hand to describe the use case, I was wondering what this might look like
from
the library perspective.
Feedback and further information most welcome!
Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
-- Bernd Oberknapp Gesamtleitung ReDI
Albert-Ludwigs-Universität Freiburg Universitätsbibliothek Platz der Universität 2 | Postfach 1629 D-79098 Freiburg | D-79016 Freiburg
Telefon: +49 761 203-3852 Telefax: +49 761 203-3987 E-Mail: bo@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Bernd Oberknapp bo@ub.uni-freiburg.de [2020-07-16 19:14]:
the COUNTER_SUSHI API usually is used for application to application communication, so I'm wondering why SAML should be considered for this case. Which libraries/consortia have suggested this and what is their use case?
I think the simple idea what for the IDP to send /something/ along to the SP so that the SP can produce aggregated reports based on the /somethings/ recieved by the IDP, ultimately providing the IDP with meaningful-to-the-IDP aggregated reports by the /somthings/ the sent along for different parts of their community. -peter
On 17.07.20 00:09, Peter Schober wrote:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2020-07-16 19:14]:
the COUNTER_SUSHI API usually is used for application to application communication, so I'm wondering why SAML should be considered for
this case.
Which libraries/consortia have suggested this and what is their use
case?
I think the simple idea what for the IDP to send /something/ along to the SP so that the SP can produce aggregated reports based on the /somethings/ recieved by the IDP, ultimately providing the IDP with meaningful-to-the-IDP aggregated reports by the /somthings/ the sent along for different parts of their community. -peter
My understand was that this wasn't about the reporting but about the APO. As already mentioned sending information to the publisher and then breaking down the COUNTER reports by that information already would be possible for the COUNTER Master Reports, so all we would have to do is to agree on what attribute should be used and, if enough publishers agree to implement this, to suggest a common extension for the COUNTER reports for breaking the usage down (similar to the Institution_Name and Customer_ID extensions defined in section 11.5 of the Code of Practice which allow to break reports for consortia down by members). There would be no need to change the COUNTER reports or the COUNTER_SUSHI API for this purpose.
Best regards, Bernd
Bingo.
We'd like to support this at Elsevier.
It is not to replace any existing reporting structures, it's just adding another dimension to them.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Peter Schober Sent: Friday, July 17, 2020 00:09 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Question about library/publisher reporting
*** External email: use caution ***
* Bernd Oberknapp bo@ub.uni-freiburg.de [2020-07-16 19:14]:
the COUNTER_SUSHI API usually is used for application to application communication, so I'm wondering why SAML should be considered for this case. Which libraries/consortia have suggested this and what is their use case?
I think the simple idea what for the IDP to send /something/ along to the SP so that the SP can produce aggregated reports based on the /somethings/ recieved by the IDP, ultimately providing the IDP with meaningful-to-the-IDP aggregated reports by the /somthings/ the sent along for different parts of their community. -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
The RA21 Corporate Pilot Report includes the suggestion to add a multi-valued schacLocalReportingCode attribute to the SCHAC schema for this purpose. Is that still the plan?
It won't be possible to break the usage down by multiple values for a user, so the COUNTER reports would include all combinations of codes that occur. For example if an institution uses codes A and B, and some users have just code A or just code B, and some users have both A and B, the result would be three entries per item in the COUNTER reports, one for "A", one for "B" and one for "A; B".
Best regards, Bernd
On 20.07.20 12:44, Koren, Meshna (ELS-AMS) wrote:
Bingo.
We'd like to support this at Elsevier.
It is not to replace any existing reporting structures, it's just
adding another dimension to them.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Peter Schober Sent: Friday, July 17, 2020 00:09 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Question about library/publisher reporting
*** External email: use caution ***
- Bernd Oberknapp bo@ub.uni-freiburg.de [2020-07-16 19:14]:
the COUNTER_SUSHI API usually is used for application to application communication, so I'm wondering why SAML should be considered for
this case.
Which libraries/consortia have suggested this and what is their use
case?
I think the simple idea what for the IDP to send /something/ along to
the SP so that the SP can produce aggregated reports based on the /somethings/ recieved by the IDP, ultimately providing the IDP with meaningful-to-the-IDP aggregated reports by the /somthings/ the sent along for different parts of their community.
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de
https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The
Netherlands, Registration No. 33158992, Registered in The Netherlands.
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
This is good input. There are analytics specialists that ensure the reports are COUNTER compliant and the changes to reporting are not done lightly.
Our first concern is to pass the data through and to have an attribute for this purpose. SchacLocalReportingCode would have been fine, in my opinion, if it made its way to a schema.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Bernd Oberknapp Sent: Monday, July 20, 2020 13:07 To: fim4l@lists.daasi.de Subject: Re: [Fim4l] Question about library/publisher reporting
*** External email: use caution ***
The RA21 Corporate Pilot Report includes the suggestion to add a multi-valued schacLocalReportingCode attribute to the SCHAC schema for this purpose. Is that still the plan?
It won't be possible to break the usage down by multiple values for a user, so the COUNTER reports would include all combinations of codes that occur. For example if an institution uses codes A and B, and some users have just code A or just code B, and some users have both A and B, the result would be three entries per item in the COUNTER reports, one for "A", one for "B" and one for "A; B".
Best regards, Bernd
On 20.07.20 12:44, Koren, Meshna (ELS-AMS) wrote:
Bingo.
We'd like to support this at Elsevier.
It is not to replace any existing reporting structures, it's just adding another dimension to them.
Kind regards, Meshna
-----Original Message----- From: FIM4L fim4l-bounces@lists.daasi.de On Behalf Of Peter Schober > Sent: Friday, July 17, 2020 00:09 > To: fim4l@lists.daasi.de > Subject: Re: [Fim4l] Question about library/publisher reporting > > *** External email: use caution *** > > > > * Bernd Oberknapp bo@ub.uni-freiburg.de [2020-07-16 19:14]:
the COUNTER_SUSHI API usually is used for application to application >> communication, so I'm wondering why SAML should be considered for this case. Which libraries/consortia have suggested this and what is their use case?
I think the simple idea what for the IDP to send /something/ along to the SP so that the SP can produce aggregated reports based on the /somethings/ recieved by the IDP, ultimately providing the IDP with meaningful-to-the-IDP aggregated reports by the /somthings/ the sent along for different parts of their community. -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de
https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands. _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.daasi...
-- Bernd Oberknapp Gesamtleitung ReDI
Albert-Ludwigs-Universität Freiburg Universitätsbibliothek Platz der Universität 2 | Postfach 1629 D-79098 Freiburg | D-79016 Freiburg
Telefon: +49 761 203-3852 Telefax: +49 761 203-3987 E-Mail: bo@ub.uni-freiburg.de Internet: https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ub.uni-...
________________________________
Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33158992, Registered in The Netherlands.
Teilnehmer (4)
-
Bernd Oberknapp -
Heather Flanagan -
Koren, Meshna (ELS-AMS) -
Peter Schober