2. Our problem
• Research outcomes scattered through various
services and data formats
• Heavy burden on researchers and managers
• Inconsistent information and impact assessment
2
16. A non solution
• Many synchronization procedures per service
• Implementation and maintainability nightmare
• No clear flow to achieve global consistency
6
19. Our solution
• One synchronization procedure per service
• Easier to implement and maintain
• Clear flow to achieve global consistency
8
20. Why ORCID?
• High coverage of predefined requirements
• High interoperability with external sources
• High coverage of the national research community
• Sustainable and open source
9
24. Main challenges
• Mismatch between data models
• ORCID may contain several versions of the same
output
• They are grouped together based on UIDs
• API 1.2 does not reflect this data model
• Inconsistent, sometimes incorrect, meta-data
11
25. Design methodology
• Focus on the what before the how
• What is the desired notion of consistency
between each service and ORCID?
• How can a synchronization procedure be
implemented to enforce such consistency?
12
26. Design methodology
• Use formal analysis methods and tools
• To verify desirable properties of all artifacts
• To generate scenarios for validation and testing
• “The first principle is that you must not fool
yourself, and you are the easiest person to fool”
Richard Feynman
13
31. Prototype
• Demoed at the FCCN community annual meeting in
February 2015
• Show compelling and real use cases
• Four PTCRIS services involved: CV, OA aggregator,
DSpace, and OJS
15
33. What’s next?
• We expect to have certified implementations of this
specification in DeGóis (CV), RCAAP (OA
aggregator), SARI (DSpace), and two local CRIS
systems by the end of 2015
• Upgrade the specification to ORCID API 2.0
• Provide synchronization as a service?
• Automatic (model-based) testing from scenarios?
17