Actually, sorry, but I think for mappings, Narrower-than is more appropriate than IS-A... should have said that earlier.
Andy -------------------- Andrew S. Kanter, MD MPH - Director of Health Information Systems/Medical Informatics Millennium Villages Project, Earth Institute, Columbia University - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology Columbia University Email: [email protected] Mobile: +1 (646) 469-2421 Office: +1 (212) 305-4842 Skype: akanter-ippnw Yahoo: andy_kanter >________________________________ > From: Ben Wolfe <[email protected]> >To: [email protected] >Sent: Monday, April 2, 2012 1:57 PM >Subject: Re: [OPENMRS-DEV] Aligning metadata UUIDs for 1.9 release > > >Leave the global property but set its value to IS_A by default instead of >SAME_AS. > >Ben > > >On Mon, Apr 2, 2012 at 1:55 PM, Wyclif Luyima <[email protected]> wrote: > >@Ben, do you mean we get rid of the global property? And always set it to >IS_A, currently the way it is, you have to set a value for the global property >otherwise the mapping gets rejected if it has no map type. >> >>Wyclif >> >> >> >>On Mon, Apr 2, 2012 at 1:35 PM, Ben Wolfe <[email protected]> wrote: >> >>Is there a ticket for this? If not, can you create one Mark? Add a >>fixVersion of 1.9.0 and it will get done before the next RC. >>> >>>Wyclif, can you create a ticket to change the default default mapping type >>>from SAME_AS to either NARROWER or IS_A as Andy suggested on the >>>implementer's thread? >>> >>>(Side note: we haven't had this many RCs since 1.2...) >>> >>> >>>On Mon, Apr 2, 2012 at 11:51 AM, Andrew Kanter <[email protected]> wrote: >>> >>>Agree... we don't want versions out there with different UUIDs... >>>> >>>>-------------------- >>>>Andrew S. Kanter, MD MPH >>>> >>>>- Director of Health Information Systems/Medical Informatics >>>>Millennium Villages Project, Earth Institute, Columbia University >>>>- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology >>>>Columbia University >>>> >>>>Email: [email protected] >>>>Mobile: +1 (646) 469-2421 >>>>Office: +1 (212) 305-4842 >>>>Skype: akanter-ippnw >>>>Yahoo: andy_kanter >>>> >>>> >>>> >>>>>________________________________ >>>>> From: Darius Jazayeri <[email protected]> >>>>>To: [email protected] >>>>>Sent: Monday, April 2, 2012 11:39 AM >>>>>Subject: Re: [OPENMRS-DEV] Aligning metadata UUIDs for 1.9 release >>>>> >>>>> >>>>> >>>>>+1 also. >>>>> >>>>> >>>>>-Darius >>>>> >>>>> >>>>>On Mon, Apr 2, 2012 at 6:52 AM, Burke Mamlin <[email protected]> >>>>>wrote: >>>>> >>>>>+1 >>>>>> >>>>>> >>>>>>On Mon, Apr 2, 2012 at 9:43 AM, Mark Goodrich <[email protected]> wrote: >>>>>> >>>>>>Do you guys agree this is a blocker for 1.9.0 RC2 becoming 1.9.0? >>>>>>> >>>>>>>From:[email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin >>>>>>>Sent: Saturday, March 31, 2012 1:17 PM >>>>>>> >>>>>>>To: [email protected] >>>>>>>Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 >>>>>>>Release! >>>>>>> >>>>>>>Agreed. This is true for all metadata like these. Even if we don't >>>>>>>program against specific UUID, it will help in the long run if >>>>>>>"packaged" metadata have consistent UUIDs. >>>>>>> >>>>>>>-Burke >>>>>>>On Fri, Mar 30, 2012 at 3:00 PM, Mark Goodrich <[email protected]> wrote: >>>>>>>I agree… though, unfortunately, I would put this as a must-fix for the >>>>>>>1.9.0 release. I will enter a ticket. >>>>>>> >>>>>>>Mark >>>>>>> >>>>>>> >>>>>>>From:[email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe >>>>>>>Sent: Friday, March 30, 2012 2:37 PM >>>>>>>To: [email protected] >>>>>>>Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 >>>>>>>Release! >>>>>>> >>>>>>>Yes, metadata added in the liquibase scripts should have set uuids >>>>>>>instead of random ones. We've done this with conceptdatatypes, >>>>>>>conceptclasses, etc. >>>>>>> >>>>>>>Ben >>>>>>>On Fri, Mar 30, 2012 at 1:39 PM, Mark Goodrich <[email protected]> wrote: >>>>>>>Just bumping this over to the dev list since I mistakenly sent it to the >>>>>>>implementer’s list. >>>>>>> >>>>>>>Burke or Ben, do you have thoughts on this? >>>>>>> >>>>>>>Thanks, >>>>>>>Mark >>>>>>> >>>>>>>From:[email protected] [mailto:[email protected]] On >>>>>>>Behalf Of Michael Seaton >>>>>>>Sent: Friday, March 30, 2012 12:21 PM >>>>>>>To: [email protected] >>>>>>>Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! >>>>>>> >>>>>>>Hi Wyclif, >>>>>>> >>>>>>>I would think that if core is automatically creating any metadata, it >>>>>>>should be doing so with fixed UUIDs. It shouldn't necessarily make >>>>>>>assumptions that these won't change (eg. there is nothing stopping an >>>>>>>implementation from deleting and re-adding them), but it should at least >>>>>>>make it default to the same UUID, IMHO. >>>>>>> >>>>>>>Mike >>>>>>> >>>>>>> >>>>>>>On 03/30/2012 12:02 PM, Wyclif Luyima wrote: >>>>>>>An implementation is only required to have at least one map type that >>>>>>>will be used as the default for concept mappings when sharing metadata >>>>>>>through occ and metadata from versions earlier than 1.9, and there is a >>>>>>>global property for it. I would be fine with explicitly picking the >>>>>>>default map type, i think should be 'same-as' and then only hard code >>>>>>>its uuid. >>>>>>> >>>>>>>Wyclif >>>>>>>On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[email protected]> >>>>>>>wrote: >>>>>>>The reason i guess why we never hard corded the uuids is because >>>>>>>typically implementations can create their own concept map types which >>>>>>>will still result in having map types with differing uuids. The reason >>>>>>>we added these is to simplify this process for them by defining the >>>>>>>widely known/used map types. >>>>>>> >>>>>>>Wyclif >>>>>>> >>>>>>>On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[email protected]> >>>>>>>wrote: >>>>>>>I've just been looking through the 1.9 liquibase changesets that handle >>>>>>>the migration from the old concept_source/concept_map tables to the >>>>>>>concept_reference_* tables... >>>>>>> >>>>>>>I've got a question regarding changeset 20110301-1030f. This change >>>>>>>inserts the core concept map types that are coming "pre-package" with >>>>>>>OpenMRS... when is does so, it assigns a random UUID to each type. >>>>>>>Don't we want to define uuids for these types beforehand, to confirm >>>>>>>that the same concept map type has the same uuid across all >>>>>>>implementations? I know this isn't how we've been doing things in the >>>>>>>past, but it seems like something we really should be considering going >>>>>>>forward. Don't we want to be able to identify that, say, concept map >>>>>>>type "NARROWER-THAN" in one implementation is the same as the >>>>>>>"NARROWER-THAN" type used in another implementation? This would ease >>>>>>>Metadata sharing, for one thing, and would also ease the sharing of any >>>>>>>other things like reports/scripts/etc that might need to be shared across implementations. >>>>>>> >>>>>>>My apologies if this has been debated before... I feel like I was part >>>>>>>of discussion previously, but I can't entirely remember the reasoning >>>>>>>for assigning random UUIDS (and obviously I wasn't convinced by that >>>>>>>arguement... :) >>>>>>> >>>>>>>Take care, >>>>>>>Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>________________________________________ >>>>>>>From: [email protected] [[email protected]] On Behalf Of >>>>>>>Daniel Kayiwa [[email protected]] >>>>>>>Sent: Friday, March 30, 2012 7:01 AM >>>>>>>To: [email protected] >>>>>>>Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! >>>>>>> >>>>>>>Greetings to everyone!!! >>>>>>> >>>>>>>We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second >>>>>>>Release Candidate) which you can get from the downloads >>>>>>>page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. >>>>>>> It has a number of bugs fixed in the core application and some bundled >>>>>>>modules. See changes since the first release candidate in the release >>>>>>>notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>. >>>>>>> >>>>>>>The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> >>>>>>>version has a new option which configures OpenMRS with the MVP/CIEL >>>>>>>dictionary, but without any patient data. If you are familiar with >>>>>>>OpenMRS and want to start a new system, this is a good place to start. >>>>>>>For developers, the standalone version now lets you specify vm arguments >>>>>>>for adjusting memory, running in debug mode, profiling with YourKit, and >>>>>>>more as per details from >>>>>>>here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>. >>>>>>> >>>>>>>We have also improved the module to help you test this second release >>>>>>>candidate using your existing data. Read more about it from: Release >>>>>>>Testing Helper >>>>>>>Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, >>>>>>> and download it from >>>>>>>here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>. >>>>>>> >>>>>>>Please help us get there sooner by giving feedback on this second >>>>>>>release candidate. If you find any bugs, report them in our ticket >>>>>>>tracking >>>>>>>system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>. >>>>>>> >>>>>>>If no major bugs are found, this will become the official 1.9.0 release >>>>>>>in a couple of days. >>>>>>> >>>>>>>Upcoming End Of Life Announcements: >>>>>>>The 1.6.x line will reach EOL with the next major release (1.9.0) >>>>>>> >>>>>>>A big thank you to the 70 developers and all who have, in various ways, >>>>>>>contributed towards this release!!! >>>>>>> >>>>>>>Daniel Kayiwa >>>>>>>On Behalf of the OpenMRS community >>>>>>> >>>>>>>-- >>>>>>>The greatest want of the world is the want of men—men who will not be >>>>>>>bought or sold, men who in their inmost souls are true and honest, men >>>>>>>who do not fear to call sin by its right name, men whose conscience is >>>>>>>as true to duty as the needle to the pole, men who will stand for the >>>>>>>right though the heavens fall. >>>>>>>________________________________ >>>>>>>Click here to >>>>>>>unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> >>>>>>> from OpenMRS Implementers' mailing list >>>>>>>_________________________________________ >>>>>>> >>>>>>>To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail >>>>>>>to [email protected] with "SIGNOFF openmrs-implement-l" in the >>>>>>> body (not the subject) of your e-mail. >>>>>>> >>>>>>>[mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >>>>>>> >>>>>>> >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Implementers' mailing list >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Implementers' mailing list >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Developers' mailing list >>>>>>> >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Developers' mailing list >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Developers' mailing list >>>>>>> >>>>>>> >>>>>>>________________________________ >>>>>>> >>>>>>>Click here to unsubscribe from OpenMRS Developers' mailing list >>>>>>>>>>>>________________________________ >>>>>> Click here to unsubscribe from OpenMRS Developers' mailing list >>>>> >>>>>________________________________ >>>>> Click here to unsubscribe from OpenMRS Developers' mailing list >>>>> >>>>> >>>> >>>>________________________________ >>>> Click here to unsubscribe from OpenMRS Developers' mailing list >>>>>>________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >>________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list >>________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list > > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
