Hi Chathuri, Should we not have a owner (user_ID) correlated in each of the resource tables (projects, experiments, all descriptors)? For instance, how will the following query traverse:
Retrieve all the projects belonging to User A belonging to gateway X? Similarly, retrieve all service descriptions owned by User A (contained within gateway x)? Cheers, Suresh On Sep 4, 2012, at 5:05 PM, Chathuri Wimalasena <[email protected]> wrote: > Hi All, > > Following is the updated structure after the discussion we had regarding > the $subject. > > gateway * > |- descriptors * > |- published workflows * > |- users * > | |- workspace > | | |- workflows > | | |- projects * > | | |- experiments * > | | > | > | > | > | > |- name > |- owner > | > | > > According to above structure, database table structure is also changed as > below. > > Gateway > gateway_ID > gateway_name > > Users > user_ID > user_name > password > > Projects > project_ID > gateway_ID > project_name > > Published_Workflow > gateway_ID > workflow_name > version > content > published_date > > User_Workflow > project_ID > user_ID > workflow_name > last_update_date > > Host_Descriptor > gateway_ID > host_descriptor_ID > host_descriptor_xml > > Service_Descriptor > gateway_ID > service_descriptor_ID > service_descriptor_xml > > Application_Descriptor > gateway_ID > application_descriptor_ID > service_descriptor_ID > host_descriptor_ID > application_descriptor_xml > > Experiment > project_ID > user_ID > experiment_ID > submitted_date > > New Registry API was committed under r1380866 and the class name is > AiravataRegistry2 which implements four interfaces > as DescriptorRegistry, ProjectsRegistry, PublishedWorkflowRegistry > and UserWorkflowRegistry. > > Please give your suggestions and feedback. > > Thanks and Regards, > Chathuri > > > > On Sat, Sep 1, 2012 at 11:08 AM, Amila Jayasekara > <[email protected]>wrote: > >> On Sat, Sep 1, 2012 at 10:01 AM, Suresh Marru <[email protected]> wrote: >>> 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? >> >> Hi Suresh, >> >> Yes it answers my question. >> >> Also can we assume that descriptors (host, application etc ...) are >> owned by a single user ? (In addition to workflows, projects and >> experiments) >> >> Let me also explain how we thought about this. >> >> A gateway can have multiple projects. A project can have multiple >> experiments. An experiment is equivalent to a workflow. So a user is >> associated with a workflow. The associated user has read, write >> capabilities to all workflows he/she designs. >> If a workflow needs to be shared, then it goes to a new state called >> "published". In published state other users can read the workflow but >> cannot do any modifications to it. >> >> I guess with your answer we need to change the structure we originally >> discussed. >> >> Thanks >> Amila >> >> >>> >>> 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 >>>>> >>> >>
