Page tree
Contents

Meeting details:

  • Date: 07 August 2015
  • Venue: Video/teleconference
  • Meeting started: 10:05AM
  • Meeting ended: 11:25 AM
  • Meeting Chair: Nigel Ward

Attendees:

  1. Daniela Nastasie (UniSA)
  2. Irina Bastrakova (GA)
  3. Marianne Browne (JCU)
  4. Michelle Teis (Independent Consultant)
  5. Nigel Ward (QUT)
  6. Peter Walsh (UTas)
  7. Siddeswara Guru (TERN)
  8. Adrian Burton (ANDS)
  9. Gerry Ryder (ANDS)
  10. Liz Woods (ANDS)
  11. Cel Pilapil (ANDS)

Apologies:

  1. Anne Stevenson (CSIRO)
  2. Conal Tuohy (VeRSI),
  3. Dave Connell (AAD)
  4. Gavan McCarthy (UNIMELB)
  5. Jingbo Wang (NCI)
  6. Neil Godfrey (CDU)
  7. Steve Androulakis (Monash)
  8. Simon Porter (UNIMELB)

Agenda:

  1. Welcome - Nigel Ward
  2. Discussion of RIF-CS change proposal and briefing paper (ANDS, RAB members)
  3. Other business - Nigel Ward/Adrian Burton
  4. Date and time of next meeting, if necessary

D I S C U S S I O N :

A. Welcome and Introduction of members

B. RIF-CS Schema recommended changes:

1.     Changes to accessRights types definitions (discussed by Gerry Ryder)

This proposal aims to:

  • provide greater clarity around the encoding and use of accessRights types
  • Change current definitions to:

Open: Data is publicly accessible online. 

Conditional: Data is publicly accessible online, subject to certain conditions.  For example:

  • an embargo period;
  • a fee applies.

Restricted: Data access is limited.  For example:

  • to a particular group of users;
  • where formal permission is granted; 
  • the data may only be accessed at a specific physical location.

Discussion:

  • Gerry started presenting the use cases that drove the need to revisit the current definitions of accessRights types.
  • Peter thought the new definitions are great. However, he presented a new scenario wherein new data are continuously added to existing ‘open’ data and in such case, the newly added data has an embargo period and will only be made available after a certain period of time.  Given the new definitions, how will they classify this type of data – open or conditional?
  • Daniela, on the other hand, discussed that ‘embargo’ for her is just like a switch that has an on-off button.  So, in essence, embargo should be classified as restricted.  When the data is in embargo period, no one is allowed to have access to it – data is not accessible, therefore, access is restricted. Once the embargo period has passed, it then becomes available and can be considered as ‘open’. She mentioned that it would be ideal for data providers to be able to automatically turn that ‘switch’ on or off depending on the state of the data.
  • Adrian agreed with Daniela and added that for data on embargo period, there should at least be a note that says something like ‘an embargo period currently applies’.  Going back to Peter’s example, if some data are open and some are embargoed, the data can generally be classified as ‘open’ however, it should explicitly state that ‘part of the data is embargoed’
  • Peter confirmed that in that particular example, they have classified the data as ‘open’ in the accessRights element and added a note in the licence element about the embargo period.  Later on, he showed the board the actual record in RDA he was referring to in his example and how it is currently being described, which is aligned to what Adrian advised.
  • Marianne thought the proposal is good and mentions that there will always be special cases wherein the current definition may not always apply.
  • Guru, on the other hand, raised his concern that even with the current definitions, he is still having trouble understanding or differentiating accessRights from rightsStatement. From the current explanation or definition in the CPG, there is not much of a difference between the two and it makes their crosswalk quite difficult. He suggested that if we were talking about rights to access the data, then maybe the best is to add this information to the location element where the URL to the data or the landing page is accessible.
  • To further get a better picture of the proposal, Nigel asked ANDS to state the purpose of the accessRights types in the first place.
  • Adrian clarified that the introduction of the accessRights types was intended to allow users to get to the data faster via the available facets. accessRights is about restraints or lack of restraints on access rather than restraints or lack of restraints about how to reuse data. So, briefly described, licence = how to reuse data, accessRights = how to access data.
  • Guru still thought that the current definitions are still confusing. For instance, when you go to the rightsStatement definition or description, it also mentions access.  We just need clearer definitions.   Another thing Guru suggested was to consider adding examples that support CCPlus.
  • Daniela then suggested that may be more useful if we use accessRights and useRights instead of just accessRights and rights.
  • Irina clarified that it is clear that rightsStatement = licensing and use of data while accessRights = access to data.
  • Michelle agreed with Guru that there should be clearer explanation or description of these elements to avoid confusion.
  • Nigel requested Guru to share some CCPlus examples. Hearing all feedback from RAB members and from ANDS, it was concluded that the proposal was accepted with the minor change to the defition wherein embargo will be moved from ‘conditional’ to ‘restricted’ and that ANDS will review and clean up the definitions of accessRights, rightsStatement and licence.

Decision:  Proposal to change definitions of accessRights types accepted by RAB with the condition that ‘embargo’ will be moved from ‘conditional to ‘restricted’.

Actions:

  • Update the proposal and move ‘embargo’ from ‘conditional’ to ‘restricted – ANDS
  • Share CCPlus examples to RAB – Guru
  • Review and cleanup the definitions of accessRights, rightsStatement and licence and share with RAB - ANDS

2.     Addition of new service type = ‘store’ (discussed by Gerry Ryder)

This proposal aims to:

  • Encoding of the Node’s data storage infrastructure as a service record in RDA
  • Be able to relate provider’s collection records to their service provider’s service record in RDA

 Discussion:

  • Michelle, Daniela and Irina endorsed the proposal
  • Guru also agreed that this is a good proposal.  He further added that there may be a need to consider adding ‘compute’ as another type of service to describe RDS nodes. He explained that if we also think about research cloud services as a ‘service’ then it may well fit as a ‘compute’ service.
  • Nigel suggested to review the current types as ‘compute’ may well fit in to any of the ones in the list.
  • Marianne agreed with Guru and cited software as a service available in the cloud which provides a ‘generate’ service and in this case the ‘cloud infrastructure’ provides a ‘compute’ service.
  • Nigel agreed that it could be another form of service that can be reviewed in the future and  went back to the table again to ask what the  board thinks about the addition of the ‘store’ service type.
  • Guru, Peter and Marianne agreed to the proposal
  • Adrian further clarified that since we will not be getting collection records from the Nodes, ANDS would like to have service records created for them so that the relationship between the collections and the Nodes can be explicitly stated in the records available in RDA.

 Decision:  Proposal to add ‘store’ as a new service type endorsed by RAB

Actions:

  • Review current service types and definitions and identify which one can be used for computational service. If none, consider adding ‘compute’ as a new service type - ANDS

3.     Addition of new identifier type = ‘fundref’ for parties (discussed by Adrian Burton)

This proposal aims to:

  • Easily identify party records within RDA which has a unique funder identifier provided by Crossref.
  • Connect with the global linked research network by using the same funder identifier as publishers use

Discussion:

  • Adrian started the discussion by saying that the proposal aims to add a new identifier type ‘fundref’, an identifier that is also a DOI but is explicitly used for funders searchable or available in the Fundref registry.  He added that best practice is to record both the DOI and the fundref unique ID for a particular party record in RDA.
  • Peter thought this was a good suggestion but also added that since FundRef has some associated projects, it may be better to use ‘fundrefID’ as the type instead.
  • Marianne endorsed the proposal adding that this will be really useful who may want to search for outputs from specific funder.
  • Adrian clarified that the ‘fundref’ identifier will be typically used to relate the collection with the funder by adding a relatedInfo of identifier type=’fundref’. 
  • Marianne agreed that this will be a lot helpful especially if a researcher somehow does not remember the grant ID but remembers who funded the research, then the relationship to that funder using ‘fundref’ can be added instead.
  • Guru endorsed the proposal.
  • Daniela and Irina also endorsed the proposal and agreed with Peter that it may be clearer if ‘fundrefID’ is used instead.
  • Guru then asked whether it is necessary to add ‘ID’ to the type even if we are already talking about the ‘identifier’ element.
  • Nigel agreed with Guru and given that we do not particularly use ‘ID’ in other identifier types, the proposal is endorsed by RAB as it is – add ‘fundref’ as new identifier type for parties.

Decision:  Proposal to add ‘fundref’ as a new identifier type for parties endorsed by RAB

 4.     Amend definition for collection-party relation type ‘has Collector’ (discussed by Gerry Ryder)

This proposal aims to:

  • Allow easier encoding of collection-party to choose the most appropriate type with confidence. 

Discussion:

  • Gerry started by stating that the proposal came about because the current definitions are vague and creates confusion.
  • Adrian added that this proposal is a bit of compromise as Guru originally requested for ‘isCreatedBy’ relationship type to be added.  After a review, it was agreed within ANDS and with Guru that legacy records may have used that existing type such as ‘hasCollector’ in a different way similar to ‘isCreatedBy’ therefore adding a new type may cause misrepresentation/misalignment of records within RDA.  So instead of adding a new relationship type (which could expand and grow – e.g. addition of ‘isGeneratedBy’, etc. in the future) and to have a clear ‘citable’ party within the collection, it was decided to extend the current definition of ‘hasCollector’ instead.
  • Michelle had no issue with the expanded definition. She added that this new definition will make crosswalk a lot easier as most metadata has ‘creator’ field.
  • Irina also endorsed the proposal
  • Nigel also agreed saying that this is a ‘catch all’ relationship and that introducing a new type would be more difficult as it would take a lot of time to get back to providers and ask them to change their records to align with the new type(s).
  • Adrian stated that the only downside of having this ‘catch all’ relationship type is that there may be 1 or 2 parties in different functions but using the same relationship.
  • Daniela agreed with the proposal.
  • Marianne also agreed with the proposal adding that this currently aligns to their current practice.
  • Peter thought the proposal was good as it makes crosswalk easier.
  • Adrian asked the board to provide some specific crosswalk examples that ANDS can use and add to the CPG.  He also added that this proposal would also help when we export records to Thomson Reuters and DataCite.

 Decision:  Proposal to amend the collection-party relationship type ‘has Collector’ definition endorsed by RAB

C.     Other Business:  None.

D.    Date and time of next meeting:

  • Adrian gave RAB a heads up that there may be some few more proposals coming in such as new collection types proposal. 
  • ANDS will send a doodle pool within the next 2 weeks to schedule the next RAB meeting for the end of September.
  • Peter suggested that it may be good to schedule a face-to-face meeting during eResearch.  Adrian, on the other hand, agreed to meeting personally as a group during eResearch but hoped that the RIF-CS changes are finalised by end of September to give some time for development and release in November.

ACTIONS:

No

Action

Responsible

Status/Comments

1

Update the proposal and move ‘embargo’ from ‘conditional’ to ‘restricted

ANDS

 

2

Share CCPlus examples to RAB – Guru

Guru

Completed

3

Review and cleanup the definitions of accessRights, rightsStatement and licence and share with RAB

ANDS

 

4

Send doodle poll for the next RAB meeting

Cel