Meeting details:

• Date: 22 October 2014
• Venue: Video/teleconference
• Meeting started: 12:05PM
• Meeting ended: 1:10 PM
• Meeting Chair: Nigel Ward

Attendees:

1. Anne Stevenson (CSIRO)
2. Dave Connell (AAD)
3. Daniela Nastasie (UniSA)
4. Irina Bastrakova (GA)
5. Jingbo Wang (NCI)
6. Marianne Browne 
7. Nigel Ward (QUT)
8. Peter Walsh (UTas)
9. Siddeswara Guru (TERN)
10. Adrian Burton (ANDS)
11. Gerry Ryder (ANDS)
12. Liz Woods (ANDS)
13. Cel Pilapil (ANDS)

Apologies:

Conal Tuohy (VeRSI), Gavan McCarthy (UNIMELB), Neil Godfrey (CDU), Steve Androulakis (Monash), Simon Porter (UNIMELB)

Agenda:

1. Welcome - Nigel Ward

2. Status of action items – Nigel Ward/ Cel Pilapil

3. Discussion of RIF-CS change proposal and briefing paper (ANDS, RAB members)

4. Other business - Nigel Ward/Adrian Burton

5. Date and time of next meeting, if necessary

D I S C U S S I O N :

A. Status of action items from previous meeting

NOTE: Link to previous meeting’s minutes  is here.

B. RIF-CS Schema recommended changes:

1.     ‘open access’ definition and accessRights element vocabulary (discussed by Gerry Ryder)

This proposal aims to:

• enable providers to better describe the ‘openness’ of the object being described
• Addition of new vocabulary terms for accessRights element and clear definition of 'open access'.  Two set of vocabulary terms proposed:
  • Option 1 (from ANDS): onlinePublic, onlineConditional, offlinePublic, offlineConditional
  • Option 2 (from UniSA):  openAccess, conditionalOpenAccess, restrictedGroup, restrictedEmbargoonlineConditional

 Discussion:

• Gerry started by recapping the discussion regarding the ‘open access’ proposal last meeting.  She pointed out that since the RAB did not agree on the vocabulary terms to use for accessRights , the proposal has been amended to include another set of vocabulary terms as Option 2 of the proposal.   Option 1, as presented in the previous meeting proposes the following vocabulary terms representing the different aspects of ‘open access’
  • onlinePublic:  the digital collection can be freely accessed via the internet.  
  • onlineConditional:  access to the digital collection via the internet but with some conditions or restrictions.
  • offlinePublic: the collection is not available online but can be accessed without any condition – freely available offline.
  • offlineConditional: the collection is not available online and can be accessed with some conditions or restrictions
• Daniela then presented Option 2.  She started by stating that the terminologies are intended to clarify what open access is and there is no longer a requirement to define it or describe it elsewhere.  She then went on by saying that replacing ‘open access’ with a different term will more likely cause confusion thus, there is no need to define our own term.  According to her, we can use ‘open access’ but then agree as a community the definition to use and adapt for RIF-CS.  She proposes the following vocabulary terms:
  • openAccess – (or Publicly available, Public Access, Free to Access, etc.) – optional accessRights type to be used with online data to identify data that can be electronically accessed for free with no conditions imposed on the user (definition of OA to be aligned to international guidelines – see Note 1)
  • conditionalOpenAccess - optional accessRights type to be used with online or offline data to identify datasets that can be accessed for free, providing certain conditions are met. For example, a free registration in the case of online datasets is required or data can be only accessed at its physical location (offline datasets)
  • restrictedGroup – optional accessRights type to be used with online or offline data - access to data is restricted to a particular group or groups of users (authentication is required and authorised users can view or access the data according to their privileges)
  • restrictedEmbargo – optional accessRights type to be used with online or offline data - access to data is restricted for a particular period of time (embargo) – after the embargo period expires the collection becomes openAccess (online data only)  or can be accessed as per the rights statement (offline data)
• Similar to option 1, these vocabulary terms are suggested and not mandatory, thus, fully backwards compatible.
• Nigel went around the table to ask each RAB member present to provide their comment on the amended proposal and their preference between Option 1 and Option 2.
• Dave preferred Option 2. According to him, as a metadata administrator, offline and offline would more likely be something that needs to be described somewhere else and not add it as part of the access condition, thus his preference for Option 2.
• For Irina, she also preferred defining access somewhere else.  She would, however, prefer combining ‘restrictedGroup’ and ‘restrictedEmbargo’ as a single term ‘restrictedAccess’.
• Adrian, on the other hand, briefly discussed the  ANDS process for managing changes to the services, the systems and to RIF-CS schema.  He echoed what the internal Change Advisory Board (CAB) thinks about ‘open access’ when this proposal was initially discussed as a heads up change for Release 14.  The CAB advise was that ‘open access’ for data cannot easily be encapsulated into one single term or one metadata, therefore defining open access can be best done with a combination of values for accessRights, licence and Rights statement.  We were advised to be careful in choosing the vocabulary terms to use.  The preference would be to describe separately the physical property that describes access and also, online/offline be defined somewhere else in the schema.
• Nigel then agreed with Adrian pointing out the importance of the different facets, which when used with the right values would be able to clearly describe ‘open access’.
• In Marianne’s point of view, either option will work assuming that the definitions are easy enough to understand and implement.  To her, Option 2 does not necessarily make it obvious whether access is online or offline.  She said that we should be careful when we implement something to describe open access.  Right now, the location element is used in different ways.  We use it to add the physical location, the URL of the data and some other things. Any automated/machine-to-machine ingest may have difficulty identifying if the data is available online or offline if it is not described elsewhere.  From a researcher point of view, Option 1 is easy to understand though.
•  According to Peter, we should be clear with our definitions.  For instance, when we say registered users, what do we mean?   He also raised a concern about the values being optional.  It poses a risk that users may make an assumption about the data’s openness.
• In Guru’s opinion, Option 2 might be difficult to implement.  For instance, if you have ‘openAccess’ as a value, but did not provide the URL, then it would not make any sense.  Also, he suggested that  ‘conditionaOpenAccess’ be changed to ‘conditionalAccess’. He then went on by saying that ‘restricted’ and ‘embargo’ are 2 different things therefor, it might cause confusion.  Additionally, if we use these proposed new types of accessRights, we should be really careful and ensure that these types align with the current values and definition of accessRights element as described in the CPG and used by the providers.
• Dave agreed with Guru and that for AAD, they use accessRights with free text to add access conditions.  Now, is this the case wherein AAD had to review their current values and align with the new types?
• Adrian said that if a certain type is used, then a corresponding value or text is expected to go along with it and Gerry confirmed that free text will remain.
• According to Anne, describing ‘open access’ will be useful to CSIRO as they only have publicly available records in RDA.  She thought though that ‘conditionalOpenAccess’ may not be a term that is easily acceptable by everyone. ‘openAcess’ on the other hand is fine since the community is getting used this term.
• Jingbo prefers Option 1 as this is aligned with NCI’s implementation.
• At this stage, Adrian raised a question to the table: ‘In both options, there is a need to clarify a scenario where: if there is a need to login to get access to the data, is there a requirement for a special category to define this?
• Responses were :
  • GA – for some there is a need to register but not to all
  • AAD – They require registration but anyone can register. There is no need for special category as they only ask for registration for reporting purposes.
  • TERN – There are others who may have stricter requirements and they may use ‘openAcess’ so it may be safe to just be careful.
• Hearing that, Adrian then clarified that if it is just registration or login then this aligns with ‘openAcess’. Anything stricter will be ‘restricted’.
• Nigel summarised the discussion by saying that ‘open access’ is open to interpretation.  The 2 options presented do not seem to cover enough facets or attribute to clearly define ‘open access’? Some questions raised :
  • Will adding a Yes/No (Online/Offline) attribute or facets to support the accessRights types required? 
  • How will these facets then be used in RDA? 
  • Should the RAB decide now or make the proposal perfect first? 
  • What is the timeline we are looking at and how to proceed from here?
• In response to above questions Adrian started by saying that we could take the first step and then improve the implementation at a later stage.
• Nigel went around the table again to hear what the members think about the implementation approach and which option the members prefer.
• Starting with Anne, she said she is happy with the proposal as it stands but afraid that changes can take longer.  She is therefore in favour of Option 2 if ‘conditionalOpenAccess’ is changed to ‘conditionalAccess’
• Guru prefers Option 2 with changes : openAcess, conditionalAccess, restrictedAccess, embargoAccess.  One thing to consider: Do the types need to be accessRights types or should they rather be defined in the location element?
• Peter raised a concern that if we don’t get it perfect the first time, it might break compatibility.  He prefers Option 2  but commented that  restrictedGroup and restrictedEmbargo are not mutually exclusive.  A data can be embargoed but restricted only to a certain group.
• Marianne said Option 2 fits better for the current values of accessRights.
• Jingbo preferred Option 1
• For GA, Irina thought  Option 2 fits well with them but only prefers the types ‘openAcess’, ‘conditionalAccess’ and ‘restrictedAccess’.
• Dave thought that since vocabulary terms can always be added overtime, Option 2 seems to be a better option.
• Daniela thought that in terms of approach, we may not get into coming up with a perfect solution and preferred that we implement something sooner rather than later.  Changes can be made later on.  She also agreed with the majority that conditionalOpenAccess may not be a good terminology. To her, it just means it is not completely open access and this covers the registration process. She was happy with whatever will be agreed by the Board and also happy to update in the future.
• In Gerry’s point of view, she is in favour of incremental changes.  Any change will require implementation changes so for her, we just have to be extra careful with how we communicate the changes and be clear to convey the message that this change is expected to evolve over time.
• Hearing everyone’s feedback, Nigel summarised the discussion by saying that majority of the Board members were in favour of  Option 2 with the following variation:
  • openAcess
  • conditionalAccess
  • restrictedAccess
• Adrian then wanted to confirm if Dave is happy to update AAD data with accessRights type ‘conditionalAccess’ but retaining current free text values
• Dave confirmed he is comfortable with it
• On the issue about defining online/offline attribute, Adrian clarified that if this requires structural change, then he is happy to add this in another RIF-CS change.
• Gerry also reiterated that the intent of this proposal was to support services over data and the previously approved proposal (@target; type = landingPage or directDownload) should be able to support the requirement of whether the data is available online or not.
• In conclusion, Nigel confirmed that this proposal is only for the initial implementation of ‘open access’.  The variation of Option 2 and the definitions shall be documented, distributed to the group for comment.  If there are no comments, then the assumption is that the Option 2 variation is accepted.

Decision:  Variation of option 2 agreed by majority

 Actions:

• Update the proposal with the Option 2 types discussed and agreed by majority  - Daniela/Gerry
• Distribute the new accessRights types and definitions to the RAB for comment  - Cel

C.     Other Business:  None.

D.    Date and time of next meeting:

• No meeting is scheduled after this.

ACTIONS: