sarah-city
commented
7 years ago Hi Hilde,
Thank you very much for this proposal on publication status. It does a good job of summarising and developing our previous discussions on this topic and publication clearly has the potential to be a valuable functionality.
Our comments are below.
Broadly speaking I think we are looking for publication to serve two purposes:
a) Documentation/archiving of key milestones in the process - for future reference and to provide an audit trail.
The milestones CV (with some tweaks to codes) and the proposal to make a list of publication packages available to access (p2 of the document) serve this purpose well
b) Communication - between tools and with external users (in the long run) and between different ESS stakholders (NCs, QDTs etc.) in the short run Here the export feature is key. We will want to ensure that exports are published in a user friendly - and editable -format. How much publication is required for communication with ESS stakeholders in practice depends in part on what we can set up as regards different access rights.
Some more specific comments on the current proposals
1) Publication status vocabulary The broad structure of this (simple, two levels) remains sound. As discussed, precise wording and definitions of milestones can be changed later. I would like to change the internal milestones around the pilot. Rather than PostPilot-SQP/TMT there should be two: Pilot - SQP/TMT (Elements agreed for pilot, export to SQP and translation) Postpilot (Elements reviewed on basis of the results from the pilot)
2) Use and listing of previous publication packages
This will be a very useful feature for archiving and documentation.
One question: At what level in the tool's hierarchy will this listing be? We suggest that the listing is located within an ESS Round (i.e. study) and that the listing contains all published packages within a study. We would also like to add a column for "Module" At least 60% of publications will be module specific and so it would be good to filter publications associated with a specific module.
3) Creating a new publication package The flexibility to publish different elements - and mix and match elements - is very welcome. The scope to publish different versions of question items and constructs has the potential to be useful in this context. Though as elsewhere in the tool the most recent version should be the default.
The table of element types on p4 is very helpful. A couple of comments:
Question constructs are usedby (in) instruments and sequences but are connected (through the question items they represent) to modules. This should be clear in the hierarchy
The status of concepts remains to be clarified (as elsewhere in the tool). Once we start to attach question items to concepts we would want to be able to publish details of the concepts and question items together.
NB under table. We think retaining the assumption that we add things all the time is the way to proceed for now.
5) Export Is there scope to export in other formats besides HTML, DDI3.2? PDF? Could someone print and edit/comment on a HTML output?
6) Assignment of publication status keys for metadata elements Step 1 and Step 2 (p4) weren't entirely clear. Please could you clarify.
7) Comments on p5 and p6 - Happy with all of this
Question: Is it possible to include two versions of the same element within the same publication package (for comparison)? Just a request for info at this point rather than a request to necessarily add this functionality.
hildeorten
liuy97
@StigNorland @liuy97
Publication status, please see proposal in attached document Publication status_des. 16_8-3.pdf