Attendance

Agenda

Welcome and call to order
Review action items from last meeting
Main Discussion: (David)
/Licence Type
/Publication Problems
/Amount Paid
/Source Funding
Other comments – deferred
Next Use Case
Date of next meeting
AOB

Supporting Materials

Agreed Actions

Add a description field following Publication Problems that’s a short list (to be provided by Stuart), with an ‘other’ option.
Action owner: Casrai
Completed by: June 5
For Amount Paid and VAT Component, keep the two fields, make labels and definitions clearer.
Action owner: Casrai
Completed by: June 5
Check with Valerie and George (include Stuart) if Source Funding should be a reference to a single entity.
Action owner: Casrai
Completed by: April 24
Carry over RIOXX requirement for Date of Acceptance and Publication Date.
Action owner: Casrai
Completed by: June 5

Discussion

We’ll review some specific items in the profile, but newer comments will likely be left for the next iteration as Casrai has not had the chance to review them. (This means agenda item 3e will be ignored.) Offline comments and input will be sought where necessary.

(a) Licence type, in Lists. Its using Creative Commons currently. Do we also need another list that captures Green, Gold etc. – use NISO? For RIOXX, with regard to the green/gold dimension, the challenge is that those short hand terms very often mean different things to different people depending on their definition of open access. The profile is for information sharing, rather than internal information so we have to avoid ambiguity. For RIOXX, the URL is the requirement for the licence type. For this use case, APCs, the current list of types is suitable. We’ll leave a new list off this use case, and perhaps return to the issue in a future use case. At that time, a list can put definitions out there to try and remove some ambiguity. Resolution: a second list will not be created at this time for this profile.

(b) Publication problems. Currently a Y/N element. Is that sufficient or should we add either a text field or perhaps a list of common problems? Two main problems that come up are the wrong licence or that an article isn’t open access. A text field could be added to allow a description to be added. In the future, common problems could be part of a list. It doesn’t have to happen right away. Providing structure to fields is desired to limit the amount of free text in a report. Might be better to have a description field that’s a list, but which contains “other”. Using the profile can identify other list values that can be added in future. Lists (and profiles, and elements) will be subject to version control. Action: Add a description field that’s a short list (to be provided by Stuart), with an other option.

(c) Amount paid. Recommendation is to keep clear delineation to base amount and any taxation. So have amount paid and VAT component, clearly defined. Summing the two would equal a total amount. There may not always be a VAT component. Label VAT Component is misleading, suggest more clarity in label and definition. Action: Keep two fields, make labels and definitions clearer.

(d) Source funding. Confirm that this is a reference to the organisation that will reimburse the APC. Not a reference to the research funding organisation. The sample data include recordings of several source funds, this may be misleading. This field should only have one reference. The amount could be broken up if there are different funds. If its multiples, the COAF Component field could be selected multiple times for a single record. Action: Check with Valerie and George (include Stuart) if this should be a reference to a single entity.

(e) Next use case. This one isn’t complete but we should be ready when it is. Casrai proposes that HEFCE (or HEFCE view of the APC use case) should be the next profile we focus on. Some information from the current use case will apply there. Sheridan has worked with Ben J. already on this. David/Sheridan will discuss Tuesday. Sheridan could also do multiple use cases at once and pre-populate a template. End of June approaching, we’re not working with a blank slate. We pay propose what we’re doing with DMP where we come back with several nearly-complete use cases to agree to by end of June. Upcoming meetings would be able to consider more than one. Peter West, after June, would be taking a Casrai profile and creating a web-based interactive tool to do some mapping.

Another item that has overlap is the Date of Acceptance and Publication Date. These will likely need better definitions, and Publication Date may need two versions, one for print and one electronic. Sometimes dates are seasonal. Refinements may be needed to the current dictionary definition. Print is typically more seasonal. Should we break apart Publication Date into Print Publication Date and Electronic Publication Date. Electronic will have a specific date, sometimes weeks or months before print publication. Sheridan might have info on this from RIOXX. Start of licence is used as that date. If there are requirements other than RIOXX for this element we need to discuss so that needs of all can be met. Action: Carry over RIOXX requirement for this. Refer to Licence Ref and Publication Date.

Important to keep in mind that the profile is for sharing information externally or across databases. Other comments in the profile will be reviewed and resolved following the meeting.