Issue 5558: Database role to be associated with person/organization (gene-expression-ftf) Source: Rosetta Biosoftware Business Unit (Mr. Michael D Miller, nobody) Nature: Uncategorized Issue Severity: Summary: Request from Catherine Ball, from Stanford University, that a database role be associated with person/organization. These roles will describe the types of privileges a person has with the data, not the type of occupation the person has. (see also MAGE ISSUE 103) (MAGE ISSUE 121) Resolution: reject the change Revised Text: Changes to the Specification: Section 2.1.2, AuditAndSecurity Replace Figure 2-3 For Security, modify the Association documentation Currently: \breadGroups\b : SecurityGroup (0..n) Specifies which security groups have read permission. \bwriteGroups\b : SecurityGroup (0..n) Specifies which security groups have write permission. Becomes: \bsecurityGroups\b : SecurityGroup (0..n) Specifies which security groups have permission to view the associated object. (where \b...\b represents boldface) MAGE-OM and the generated MAGE.xmi are updated, eliminating the current associations from Security to SecurityGroup and adding a more general association. MAGE-ML.dtd Modify Element and Attlist declarations for Security Currently: readGroups: Specifies which security groups have read permission. writeGroups: Specifies which security groups have write permission. Becomes: securityGroups: Specifies which security groups have permission to view the associated object. Currently: <!ELEMENT Security ((%Identifiable_content;), Owner_assnreflist?, ReadGroups_assnreflist?, WriteGroups_assnreflist?) > Becomes: <!ELEMENT Security ((%Identifiable_content;), Owner_assnreflist?, SecurityGroups_assnreflist?) > Modify Element and Attlist declarations for SecurityGroup Currently: <!ELEMENT ReadGroups_assnreflist (SecurityGroup_ref+) > <!ELEMENT WriteGroups_assnreflist (SecurityGroup_ref+) > Becomes: <!ELEMENT SecurityGroups_assnreflist (SecurityGroup_ref+) > Actions taken: July 29, 2002: received issue December 11, 2002: closed issue Discussion: Request from Catherine Ball, from Stanford University, that a database role be associated with person/organization. These roles will describe the types of privileges a person has with the data, not the type of occupation the person has. The proposed change would have required an extensive reworking of the AuditAndSecurity package An alternative proposed change that made the Security and SecurityGroup association more general. The SecurityGroup instance could then provide more information through its association to Description. End of Annotations:===== X-Server-Uuid: F7D3E4A3-3C15-41D2-AC5D-A7D3F094E28F From: "Miller, Michael (Rosetta)" To: "'Juergen Boldt'" cc: gene-expression-ftf@omg.org Subject: Gene Expression FTF issues Date: Mon, 29 Jul 2002 07:30:43 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 115B8FEF18115-01-01 Hi Juergen, Here's the last batch. Officially, I guess I'm entering them but these are collated from the MGED efforts for which there is no clear consensus yet. thanks, as always, Michael Michael Miller Senior Application Developer Rosetta Biosoftware michael_miller@rosettabio.com www.rosettabio.com Request from Catherine Ball, from Stanford University, that a database role be associated with person/organization. These roles will describe the types of privileges a person has with the data, not the type of occupation the person has. (see also MAGE ISSUE 103) (MAGE ISSUE 121) X-Server-Uuid: F7D3E4A3-3C15-41D2-AC5D-A7D3F094E28F From: "Miller, Michael (Rosetta)" To: "'jason@openinformatics.com'" cc: "'mged mage'" , "'GE FTF'" Subject: RE: [Mged-mage] Call to vote: Issues #5552, #5553, #5555, #5556, #5558, #5560 Date: Mon, 26 Aug 2002 11:43:47 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1174AAF411042-01-01 Hi Jason, You raise some good points, but there is the minor consideration that these are already sent to vote for the FTF with the deadline of this Friday. I'm forwarding this to the FTF for their considerations for voting on the bottom two issues, #5558 and #5560. The FTF can decide to accept the recommendations I put out or not to accept them. If they aren't accepted, then I can send out a further recommendation along the lines you outline. > If we add a special rule like 'you can have either This or That but > not both' and the rule is not encoded directly in the XMI file, then > we will have to add a third type of file that is used by MAGEstk, as > well as adding some special logic code to the generators. It looks like soon this won't be necessary because the rules in the > comments can be specified in a formal UML rules language, the Object Constraint Language (OCL), which is pretty stable but complex. A revision of OCL > is currently going through the OMG (OMG Document ad/02-05-09) > This will break MAGEstk for some time to come. I'll probably get the > Perl code working, after I figure out how best to do this, but who > will make the Java changes? It turns out that the above rule is encoded in the constraints of the > Model, if two association ends have the same rank, then they are a choice > group in the dtd. This is already in the Java code by adding the rank # to the association end object. Then the generating code orders the > associations by rank and checks for two associations that have the same rank. Note that the Java language can't enforce this directly, one either needs to add fairly complex code to have one association or the other but not both, or merely add a state check to the generated FactorValue class. The current generated java code simply lets the DTD enforce this. Note in the PNG the rank constraints for the associations from FactorValue and the change in the updated dtd: The Java code finds it in the XMI via Constraint-G.711 rank: 1 ... > After meeting with the SMD folks and discussing this issue with them, > I'd like to propose the following compromise. Rename SecurityGroup to > Role, and replace the two existing associations from Security > (WriteGroups and ReadGroups) with a single association, roles. > > Also it keeps it generic enough, that it is still within the scope of > the model, and is useful to other groups for describing what SMD wants > to do. But I would argue we aren't encoding specific Security information in MAGE--by specifying what SecurityGroup a person belongs to, the database already knows what database rules that person has. The only reason that should be in the MAGE document is if it can be used, and I don't think MAGE should be used to change people's db roles. It also adds no more information to the Gene Expression data. The Security Group can get used not by altering the security group but by setting up a reference from the Describable object to the existing security group. To exchange that level of DB information, I think should be a different document with a DB specific XML Schema or DTD. I haven't investigated, but does anyone know of one that exists? > ===================================================================== > > > > Recommend that the specification include a section on how > numbers are > > to be formatted. > > How about using the W3C XML Schema recommendation for the integer and > floating point numbers? This is a much more rigorous definition. > > It also removes any commas from the numbers, so 1,000 is invalid and > 1000 is valid. > > It also provides for INF, -INF, and NaN for floating point numbers. Good point, but see above, the change is already being voted on. Your earlier suggested format does specify no commas, though. I'm inclined to reconsider this, I will probably vote no on the recommendation then suggest this for the next round of voting. thanks, Michael (p.s. the PNG for Experiment that I sent out had a mistake on the cardinality of the Measurement association of FactorValue, it's correct in this version) > -----Original Message----- > From: jason@openinformatics.com [mailto:jason@openinformatics.com] > Sent: Sunday, August 25, 2002 5:12 PM > To: Miller, Michael (Rosetta) > Cc: gene-expression-ftf@omg.org; 'mged mage' > Subject: Re: [Mged-mage] Call to vote: Issues #5552, #5553, #5555, > #5556, #5558, #5560 > > > "Miller, Michael (Rosetta)" writes: > > > Issue #5556: Specifying a FactorValue needs to be more flexible > > =============================================================== > > > * add a rule that FactorValue has *either* a Measurement *or* a > > OntologyEntry. > > One word of caution is that MAGEstk currently utilizes two bits of > information from doing it's job: > * MAGE.xmi - the model > * package-list.xml - specifies the order of the 'packages' in MAGE-ML > > If we add a special rule like 'you can have either This or That but > not both' and the rule is not encoded directly in the XMI file, then > we will have to add a third type of file that is used by MAGEstk, as > well as adding some special logic code to the generators. > > I'm not opposing the change, I just want people who vote to realize > the impact of the decision. > > This will break MAGEstk for some time to come. I'll probably get the > Perl code working, after I figure out how best to do this, but who > will make the Java changes? > > > Issue #5558: Database role to be associated with person/organization > > ==================================================================== > > > > A database role should be associated with > person/organization. These > > roles will describe the types of privileges a person has > with the data, > > not the type of occupation the person has. > > > > Recommend reject change. Change would require modeling > information beyond > > the scope needed to interchange Gene Expression data. > > After meeting with the SMD folks and discussing this issue with them, > I'd like to propose the following compromise. Rename SecurityGroup to > Role, and replace the two existing associations from Security > (WriteGroups and ReadGroups) with a single association, roles. > > This both simplifies the model, and provides some needed > flexibility. I originally proposed the Security SecurityGroup model > based on GeneX's security model. Since then, I've discovered it is too > limited, and have expanded it as well. > > Also it keeps it generic enough, that it is still within the scope of > the model, and is useful to other groups for describing what SMD wants > to do. > > > =========================== > > > > Issue #5560: For interoperability, need a rule for > formatting numbers > > > ===================================================================== > > > > Recommend that the specification include a section on how > numbers are > > to be formatted. > > How about using the W3C XML Schema recommendation for the integer and > floating point numbers? This is a much more rigorous definition. > > It also removes any commas from the numbers, so 1,000 is invalid and > 1000 is valid. > > It also provides for INF, -INF, and NaN for floating point numbers. > > jas. > Experiment1.png X-Server-Uuid: F7D3E4A3-3C15-41D2-AC5D-A7D3F094E28F From: "Miller, Michael (Rosetta)" To: "'jason@openinformatics.com'" , mged-mage@lists.sourceforge.net cc: "'GE FTF'" Subject: RE: [Mged-mage] Re: #5558 Date: Tue, 3 Sep 2002 15:31:00 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 116BE93825255-01-01 Hi Jason, That sounds reasonable. We are almost out of time for changes for the FTF report but I will send out this recommendation to the FTF for a vote as an alternative to no action tomorrow morning. This suggestion may break some existing XML/code but sounds minimal. Comments? Michael > -----Original Message----- > From: jason@openinformatics.com [mailto:jason@openinformatics.com] > Sent: Tuesday, September 03, 2002 3:22 PM > To: mged-mage@lists.sourceforge.net > Subject: [Mged-mage] Re: #5558 > > > "Miller, Michael (Rosetta)" writes: > > > I recommended no action because it wasn't clear to me how to get > > both these concepts in without major changes. > > Then what about leaving the name SecurityGroup in place, but removing > the two specific associations, ReadGroups and WriteGroups, and making > a single association, SecurityGroups? > > That simplifies the model and still makes it (slightly) more generic. > > jas. > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mged-mage mailing list > Mged-mage@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mged-mage >