Meeting details:

• Date: 11 September 2015
• Venue: Video/teleconference
• Meeting started: 10:05AM
• Meeting ended: 11:00 AM
• Meeting Chair: Nigel Ward

Attendees:

1. Anne Stevenson (CSIRO)
2. Daniela Nastasie (UniSA)
3. Dave Connell (AAD)
4. Gavan McCarthy (UNIMELB)
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. Conal Tuohy (VeRSI)
2. Irina Bastrakova (GA)
3. Jingbo Wang (NCI)
4. Marianne Browne (JCU)
5. Michelle Teis (Independent Consultant)
6. Neil Godfrey (CDU)
7. Steve Androulakis (Monash)
8. Simon Porter (UNIMELB)

Agenda:

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

D I S C U S S I O N :

A. RIF-CS Schema recommended changes:

1.     Addition of new RIF-CS collection types (discussed by Adrian Burton)

This proposal aims to:

• 1. Reflect more accurately the kinds of objects that research organisations are registering in the ANDS registry using the collection element. 
  2. Allow the typing of such research assets within the ANDS registry, to allow segmenting of the ANDS holdings'
  3. Allow RIF-CS compatible systems (not necessarily the ANDS Registry/RDA)[1] to ‘ingest’ information about research assets (such as publications) that may not have connections with collections/datasets (whereas publications are currently always relatedInfo about a collection).  
  4. Allow registries that use RIF-CS to include ontologies and other classification schemes which are considered as research assets
  5. Provide an extensible precedent in the schema to deal with future research asset types from specific disciplines eg humanities and social science.
  6. Resources such as models are sometimes cited or referenced in scholarly communications or counted as the output or impact of research; allow them to be processed in the same way as citable datasets  (eg exported to Thomson Reuters Citation Index).
• 
  

  ---

  [1] Note there is no plan to change the deposit policy

Discussion:

• Adrian presented first the advantages of adding new collection types sourceCode, classificationScheme, publication: 
  • be able to encode properly those collections of type software or source code instead of simply choosing 'collection' as the type and there are many other systems out there that use RIF-CS
  • to allow other systems not using RDA encode metadata properly
  • to differentiate describing a software as collection other than a service
• Daniela thought that instead of using 'publication', we could re-define 'repository' to also include publications
• Adrian then pointed out that redefining the existing type is more difficult unless it is really needed (for instance, if it is entirely wrong).  Although a typical repository may have publications and so as other types too.
• Gerry added that we  also do not want to use 'publication' in RDA as it is most applicable only to other systems.  Unlike source code, we already have quite a number of these in RDA
• Dave suported the proposed changes and also do not quite agree with including publications to repository
• Gavan also agreed with the proposed changes.
• Peter, on the other hand, requested for more clarification on the intention of adding 'publication' as a collection type. To him, it seemed beyond the original scope of RIF-CS.
• Adrian replied to him by describing the Research Data Alliance (RD-A).  The idea is to allow RD-A to enable connections between parties, publications and data from everywhere (e.g. DRYAD, ORCID) using RIF-CS. He then added that previously, institutions use RIF-CS, that in their business, do not differentiate data against publications.  The new types will also allow ANDS to export to the likes of CERIF where there are other types such as publications.
• Anne totally agreed with the proposal pointing out that this is something that CSIRO researchers who use source code and for publications, it will be really useful for the likes of journals to be included.
• Guru expressed his agreement with Dave that sometimes sourceCode can  be considered as a repository.  For publications, he added that research community may have an issue with this.  For classificationScheme, for him, an anthology can be useless without a service. Overall, he felt that adding more types would be more problematic.
• Adrian then responded to Guru's comments by saying that we would be hesitant to redefine repository as it is currently described now.  And if there may be some confusion between sourceCode and repository, we will then add github as an example in the definition. In regard to the classificationScheme, he explained that a vocabulary service can be described as a service while the different SKOS files, for instance, can be described as a collection.  Again, we will have to provide some guidance and examples here.
• Gerry then added that after a number of hours of internal discussion within ANDS, simple way of saying it is that the repository is where you get the source code.
• Daniela then suggested that we could probably introduce a more granular type - such as levels or hierarchy of collection types.
• Adrian further explained that since a type is mandatory, adding granularity maybe cumbersome to  others.  If there is a requirement in the future, then we could probably introduce a lower level/granular type as an optional sub-element or attribute.
• Nigel then asked Adrian if RD-A is interested in defining a more granular type of publication and the answer is No. 
• Having heard everyone around the table, Nigel then summarised the issues raised.  One issue is that it looked like we may get people confused people with the notion of collection vs an item within the collection. He thought that we are trying to use a collection and an item at the same level.
• Gerry then shared the ISO2146 document and Adrian explained that ISO2146 describes that the difference between a collection and an item could be dependent on who is describing it. For instance, a publication can be described as a collection and the tables, graphs, texts and diagrams within the publication can be all items.
• Nigel then asked ANDS how a publication is currently being described in RDA.
• Adrian explained that the moment, any publication is encoded in RDA as a relatedInfo of type publication - that is in relation to the collection being described. This however, does not satisfy RD-A's requirement. 
• Nigel then reiterated that a guidance should be well-written to help people in deciding what type of collection to use when using RIF-CS.  He then went around the table to hear everyone's decision on the proposal.
• Guru commented that it was a good proposal. He then added that clearer definitions and more examples may be useful for sourceCode.  He ended by saying that he still felt that ontology should definitely be a service.
• Gavan on the other hand expressed his thought that there is historically a strong case to include ontology as a collection and he supported that proposed changes
• Anne was happy to approve the changes
• Peter agreed not only with the proposed changes but also on the comment that definitions need clarity
• Daniela also agreed with the proposal apart from her previous comment about publication.  She also agreed that there needs clarity.
• Nigel also agreed and added that the difference between what the schema and what RDA is describing should be really clear.
• In summary, it was agreed that clearer definitions and guidance with specific examples must be written to help people in deciding what type of collection to choose when using RIF-CS.  The documentation should have scenarios or clear definitions/distinctions between 
  • collection and item
  • RIF-CS schema and what RDA is describing  
  • service and collection (esp in the context of sourceCode)
  • repository and sourceCode
  • repository and publication

Decision:  After going around the table, the proposal to add new collections types (sourceCode, classificationScheme and publication) was considered agreed and endorsed for implementation.

Actions:

• Update collection types descriptions and be able to provide more examples– ANDS

C.     Other Business:  None.

D.    Date and time of next meeting:

• RAB agreed that there is no need to convene all members to discuss changes to collection types descriptions and examples.  The proposed documented can be reviewed outside the RAB meeting. 

ACTIONS: