Notes and Action Items

printer friendly

Friday 3rd December TMB & Technical Meeting.

• Who is the intended audience and what is the purpose of this documentation?
• General consensus: It should be for a public audience describing in detail the key components; Functionality; description based on the architecture in terms of what we have done.
• D3.5 needs to be interpreted for Technical documentation
• Agreed:We need to set up a Working group for D3.7 with the integration of Taxonomy..
• It should be a Public document which should be tangible for future developers i.e. how the GUID will function; our BHL Schema; how we deliver our archive and storage; How people interface with the portal; Multilinguality; how people will ingest etc. (all in moderate detail).
• It should be documented as a Developer’s Guide, APIs, User Guide, Architectural documentation in relation to D3.5.
• The architectural diagram has changed and we now need to embed Taxonomy.
• SuggestionAdrian: We should deliver a small document with annexes which will be the bulk of the document for all the deliverables.
• Maybe produce an Executive Summary document with annexes for a wider audience.
• (i.e. standalone documents for various interest groups).
• Q: How large should the document be?
• A: 100 pages maximum
• QLee: are we going to allocate a fixed amount of resources to do this documentation or do the whole development?
• AAdrian: We have to have the appropriate level of documentation for the Deliverable.
• Delivery is crucial but we still need to document for users.
• For the Tehnical Documentation, we need a detailed plan.
• Henning: The Audience is for the Reviewers, they need to see we have incorporated sufficient information for our target audience.
• Documentation will follow after the remaining deliverables.
• D3.9 should come together with documentation finalising comp. from D3.7.

• Working group to be established consisting of:-
• AIT, ATOS, Wolfgang, Taxonomy requirements, Patricia, Heimo, Boris (GRIB Integration).
• We need to fix our architecture first in terms of integration of taxonomy.

• Within the next week confirm members of the group.
• Start writing by the end of January including new architectural requirements.
• Adrian to establish Parallel groups by end of December.
• Aim:Table of Contents in place for the output of D3.7 - start fleshing out the document from end of Jan to end of March.
• Start with document D3.4 and D3.2 which is quite generic.

• Updated architecture of US is available…hence we can re-use their code and redeploy it for our documentation.
• Physically there has to be 2 sets of code i.e. the basis identical but different (2 user interfaces).
• Major mulit-lingual access with the BHL-portal will have to be augmented into the code for the portal including Cat of Life name finding.
• We will use some of the BHLUS components.
• Mike /Phil have the expertise i.e. a joint US development team in terms of a development roadmap. They can help us code-develop for a Single platform.
• There really should be 1 global development.
• Lee: We still need to develop our own Pre-ingest, Ingest, we start off with Drupal base for the portal, GRIB - we have to do (develop our own), Data Management – they are also using Solr for search engine. Hence we are really using the same components as opposed to copying code.
• QCF: Can we re-factorise the Portal?
• A: Yes, the ‘Access’ part of the architectural diagram which is .NET code-based.
• We can re-mirror specification into a new technology i.e. re-engineering.
• Open Source language for portal is preferred for technology.
• In BHLUS system, the Portal and Access are both based on .NET.
• Adrian: A ‘Strategy of Convergence’ is what we are trying to do here not taking it all apart. We can adopt existing technology. US are refactoring anyway and for the Consortium we can have the same look and feel and if US iterations are using Drupal etc then we can use that.
• Regarding the Access Component – converge/align with similar outputs as BHLUS as a strategy for our architecture….Hence outputs should be aligned.
• Q: What about Statistic tools, search engines and taxonomy?
• AAdrian: Requirements should be documented for statistical tools –
• Agreed: WP2 to provide requirements/Use cases.
• We should look at services the US provides as a framework for portal (.NET). as a minimum our portal should provide similar services but convergent development on an open source platform in order to ensure the system is sustainable.
• US are also looking to move onto a Drupal development.
• AIT Confirmed: We are publishing our code as Open Source – free software etc. as a drupal component.
• ACTION 2: Proposal for the Licence…Walter will do this shortly. (end of the Year deadline).
• QLee: How many Search Engines will there be?
• All agreed with Lee (Atos): Propose for 1 by default until users inform us otherwise if 1 is not sufficient.
• This should be Evaluated against use cases within the Working Group..Lee (Atos).

• Kick-off for Working Group session– early January 2011.
• Finish initial stage on return from Jan visit to Lib.Alexandria - end of January 2011.
• Multiple workstreams - Adrian will run some of the streams in parallel via email i.e. looking at statistical tools, taxonomic tools.
• Individuals can be responsible for single components. (Access, Portal Components).

• Tasks added to Scrum backlog:
• Sprint #402: Finalisation and Ratification of BHL-Europe architecture.
• Sprint #510: D3.7 Table of Contents