DINA "compliance"

What is / makes a DINA compliant module?

Striking the right balance between Freedom and Control…

…using MUST / SHOULD / COULD requirements…

Web UIs would get their data through Web services through versioned and documented web APIs.

Open understandable licenses for code and content… (MIT/GPLv3 and Creative Commons)

• Provide collaboration platform and suggest tools and methods and invite to meetings
• Collate and share overview, providing DINA architectural road map and directions, unified “branding” assets (logos, stylesheets etc)
• Conflict resolution / voting capacity for controversial architectural topics
• Capacity to “certify” or validate and whitelist versions of DINA components / packages
• Determine which packages are stable and collate the reference DINA Web “distro” as a VM?
• Organize focus group and testing efforts of packages / modules?

• Code repositories online, public access (github)
• Blog, Wiki, Mailing list
• Meetings and workshops
• Chat channel (IRC)
• Potentially JIRA/REDMINE or equiv if github is not enough

What makes up a valid DINA module, then?

SETF (software engineering task force) formulate MUST, SHOULD and COULD requirements that needs to be fulfilled.

SETF takes on the role to validate these and test modules/packages and put together stable versions into a distro / VM / “system”.

• Deployable on open source stack servers, avoiding vendor lock-in and non-free licenses, deployment instructions for system integration purposes provided
• Data components - data served through Web APIs (REST)
  • Documented (in English) and versioned
  • Examples with a tutorial using curl to demo data migration
• UI components - primarly web based UIs
  • All required functionality required by UIs should be exposed in the web data APIs

• Can be deployed on popular linux server OSes
  • Mint/Debian for server OS, Mint/XFCE for desktop OS based tools
• Can be deployed in a popular standard open source application server
  • Both JSON and XML responses from REST web services
  • at least on JBoss/Wildfly if Java EE is used (http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/), also Tomcat and Glassfish?
• Provide pre-packaged VMs available for download online, preferably along with a reference implementation online with public URL

• System architectures harmonizing with the Bouchout declaration [http://www.bouchoutdeclaration.org/declaration/]
  • open access to data
  • understandable licenses
  • open linked data / comply with semantic web / www v3 aka ggg - great global graph - friendly
  • make use of persistent identifiers (http uris)

An “open spirited” international collaborative effort to create a collection management system to be used at national levels.

It exists today and it evolves in the directions we have discussed in the last few days at the workshop. You are welcome to take it and/or make it…

• How to package and test modules, verification/certification?

• Detailed discussions of module road map?

• Branding, names - what about DINA Web?

• What “standards” should be followed? Bouchout?

• What service to deliver acc to EUBON?

• What should be perceived as “competition”?