[Fim4l] Statistics issue use-case

Peter Gietz peter.gietz at daasi.de
Wed Apr 10 15:35:46 CEST 2019


Hi Nick,

this is IMO a very good idea and was my first thought when I heard that 
RA21 supports Coco, which version ever. An entity category for 
commercial publisher's offerings would be a much better way to specify 
respective attribute release policy.

@all: Entity categories allow for configuring release policies per group 
of services instead of per individual Service Provider.

Cheers,

Peter G.

> > If you think this is a mistake you can provide your input into the
> > amendment process that will likely begin soon for an R&S "2.0" spec,
> > but as it stands the R&S spec and FIM4L use-cases have zero overlap.
> This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.
>
> Best Regards,
>
> Nick
>





Am 09.04.19 um 23:02 schrieb Nick Roy:
>
> On 9 Apr 2019, at 9:04, Peter Schober wrote:
>
>> * Jiri Pavlik <jiri.pavlik at mzk.cz> [2019-04-09 14:28]:
>>> Do you find eduPersonEntitlement or eduPersonScopedAffiliation attribute
>>> better fit for authorisation when faculty, institute students and employee
>>> need to be recognised according to license terms?
>> Some SPs only support one (when talking about authorisation and
>> entitlements I mean the "common-lib-terms" attribute value
>> specifically), some can support both (with configuration; personally
>> I'd wish the SPs would just check for one and then fall back to the
>> other!), some may only support affiliations.
>> That's the status quo which is therefore more complex than necessary,
>> IMO -- at least as long as we're talking about institution-level
>> licensing.  (For anything more fine-grained than that both
>> ePE=common-lib-terms and ePSA=whatever at example.edu are equally
>> unsuited, as we've established earlier. So /that/ specific use-case
>> would still need agreement and standardisation, AFAICT.)
>>
>> I think I've made the case here previously that the "common-lib-terms"
>> ePE value has the big advantage of being invariant and the same from
>> every IDP and for every SP (for the use-case it's been defined for),
>> whereas eduPersonScopedAffiliation handling usually requires bilateral
>> negotiations between the institution and the e-resource provider
>> (sometimes via a self-service web UI, sometimes by filling out
>> spreadsheets with data that's already contained in the SAML Metadata
>> of the federation, etc.)
>> So for the same use-case ePE has clear advantages.
>>
>> ePE with the "common-lib-terms" value is less common in some very
>> large federations, though, e.g. within the UKfederation.  That matters
>> because effecting change there would mean having to convince
>> potentially hundreds of service provider to change.
>> (As long as those service providers also checked for
>> the "common-lib-terms" ePE first and fell back to their current use of
>> ePSA everything should "just work" for most every institution.)
>>
>>> However eduPersonEntitlement is missing in R&S attribute bundle.
>> That is irrelevant as the REFEDS Research & Scholarship specification
>> explicitly states that it "should not be used for access to licensed
>> content such as e-journals." ([1], Section 1, "Definition").
>>
>> If you think this is a mistake you can provide your input into the
>> amendment process that will likely begin soon for an R&S "2.0" spec,
>> but as it stands the R&S spec and FIM4L use-cases have zero overlap.
> This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.
>
> Best Regards,
>
> Nick
>
>> -peter
>>
>> [1] https://refeds.org/category/research-and-scholarship
>> _______________________________________________
>> FIM4L mailing list
>> FIM4L at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
>>
>> _______________________________________________
>> FIM4L mailing list
>> FIM4L at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20190410/f9ff40e9/attachment.html>


More information about the FIM4L mailing list