Public data

[atarkowska]

As the consequence of the sharing data, OMERO needs to allow people to make their data public (accessible in Internet).

Web Usage

User should be able to generate a link to the public data, for example:

• http://host/user_name/public/image/1/
• http://host/user_name/public/dataset/2/

This feature was based on the webmobile prototype, and is now implemented using decorators that can automatically login an "anonymous" user for all supported groups.

Other supporting features that went into this requirement include:

• the decorator support in web itself
• differentiation of read-annotate and read-write groups
• easier (and faster) changing of group permissions

[jmoore]

A few requirements from Jason:

• User should be able to look at Project, Dataset, Image, Screen, Plate, Well, Tag, TagSet? and immediately that container 'published'. This specifically means that from that point on, that data can be access from a simple URL, without a sessionid in standard web browser.
• In the fullness of time, we can think about wiki's, etc, but I wouldn't do this right away.
• We will need to standardise annotation strategy and expression of those annotations, for access by search engines and other machines. For examples on this, we might look at Uniprot, at least for functional annotations, OME-XML for microscope annotations and so on.
• Annotations on data, including analyses etc., should be optionally published.
• A published image should contain whatever metadata is necessary (metadata in a web sense, of which our standard understanding of metadata is a subset) so that image data can be indexed and found using queries the world now uses . "Swedlow taxol kinetochore' doesn't get me to the JCB DV (or wherever such data should reside), but it should. This point is probably most important-- published data should be searchable, in the way the world understands the word 'searchable'. We may need to do some work to define how doi's are expressed, and what opportunities there are for self publishing-- whatever is the standard way of doing this on the web is what we will have to do, preferably in the first release of this.

Releasing data, systematising the annotations on data (while continuing to allow all the freeform stuff), and making data searchable, are probably the priorities here.

[jmoore]

Closed #320 ("chgrp") as duplicate of this requirement. #3532 (chgrp server side) branch is at ​https://github.com/joshmoore/openmicroscopy/tree/3532-chgrp. Jean-Marie will start an insight branch and new story under this req which shows multiple servers/groups in the UI (for dragging from one to the other, etc). We will need to evaluate the same work on the web side in the new year.

Though not all of the user stories list here will be completed, some of these features will likely be the most user-impacting part of 4.4 so changing to "critical" and 4.4.

[jmoore]

Original "Initial public data work" text from #3527:

== Day 3 (Wed., the 17th) ==

Public data disussion
    * Implementation options that were discussed
        * Using the "user" group, i.e. the common space
        * One share per image or one big share
        * Multiple public groups v. one public group
        * Using world flag per row (in addition to group)
        * Subgroups
        * Copy to a public server
        * ACLs
    * Requirements that were discussed
        * Google-able
        * Optional annotations
        * Object URL
        * Collaborative containers
        * Unpublish
        * in-group, between-group, public sharing
        * protecting binary data
    * Other items
        * @@check share performance
        * adding licensing/copyright information on "publication"
        * any form of writing or linking on public data?
        * refactor or rollback or add shares to Insight. Needs UI investigation.
    * Two primary solutions to be investigated
        * Use chgrp for collaboration and row-level world-read for publishing
        * Subgroups

[jburel]

This requirement is very large and will probably be pushed from milestone to milestone.

[jmoore]

Open stories are all in other milestones (Unscheduled or Future). I've linked them into a follow-up requirement #9303. Closing.