On Aug 31, 2012, at 5:23 PM, Amila Jayasekara <[email protected]> wrote:
> Hi Suresh, > > Could you please elaborate what you meant by "1 project owned by a > single user" ? > I am trying to figure out what sort of actions are allowed when a user > is an "owner" of a project. Hi Amila, The data privacy is a complex topic, thats one of the long term best interests of Airavata to align and reuse the work done by projects like OODT. In true short term, Airavata registry should suffice and keep the focus on maturing the core features and bring them to a 1.0 state. Back on the topic, by default users would like to keep data and metadata private for a certain time. This window varies from use case to use case, but roughly it will be 12 to 18 months. During this time, the user analyses the data or publishes results. This also includes the recipe which was used to generate the data, which in Airavata case is the Workflow and the inputs and configurations. There is a growing push on depositing data and metadata into public repositories. So summarizing, Airavata should by default make the workflows, projects and experiments within it owned and accessible by a single user or the owner of the data. At the same time, we should consider capabilities to share these data (at experiment or project level) to a set of users, or groups or make them public. Does this answer your question? Suresh > Thanks > Amila > > On Fri, Aug 31, 2012 at 5:08 PM, Suresh Marru <[email protected]> wrote: >> Hi Chathuri, >> >> This is a very good list. Few suggestions, I think Descriptors and published >> workflows should be moved outside and right within Gateways. Also each user >> might have multiple projects and 1 project is owned by a single user. So I >> think it should be Users and then multiple projects within it. >> >> Suresh >> >> On Aug 31, 2012, at 5:02 PM, Chathuri Wimalasena <[email protected]> >> wrote: >> >>> Hi All, >>> >>> We had a discussion on how airavata registry data should be categorized and >>> came up with the following structure. >>> >>> Gateway >>> |- Project1 >>> | |- Descriptors >>> | |- Published workflows >>> | |- User A >>> | |- unpublished workflows >>> | |- experiments >>> | |- workflow >>> | |- nodes >>> | >>> | >>> | >>> | >>> |- Project2 >>> | |- user A >>> | >>> | >>> >>> According to the above structure, below table structure was designed for >>> the mysql database which will be replacing existing backend jackrabbit >>> database. >>> >>> Gateway >>> gateway_ID >>> gateway_name >>> >>> Projects >>> gateway_ID >>> project_ID >>> >>> Public_Workflow >>> project_ID >>> workflow_name >>> version >>> content >>> published_date >>> >>> User_Workflow >>> project_ID >>> user_ID >>> workflow_name >>> last_update_date >>> >>> Host_Descriptor >>> project_ID >>> host_descriptor_ID >>> host_descriptor_xml >>> >>> Service_Descriptor >>> project_ID >>> service_descriptor_ID >>> service_descriptor_xml >>> >>> Application_Descriptor >>> project_ID >>> service_descriptor_ID >>> host_descriptor_ID >>> application_descriptor_xml >>> >>> Experiment >>> project_ID >>> user_ID >>> experiment_ID >>> submitted_date >>> >>> All suggestions and feedbacks are most welcome. >>> >>> Thanks and Regards, >>> Chathuri >>
