Well, I already have several "categories" that I am representing as concepts because I need translation and hierarchies. Didn't know that the concept police would be coming after me for doing so.
From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Tuesday, April 17, 2012 2:01 PM To: [email protected] Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements @Roger, I think we should follow the principle of lazy evaluation, i.e. version 1 will support the "minimum viable product" that reporting needs... @Mike, I'd suggest a module id of "category", but your others seem fine too. -Darius On Tue, Apr 17, 2012 at 10:46 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: I would make sure that category supported a hierarchy; it should include hierarchy numbers or other features to make it easy to select all the members of the same hierarchy at once. I would include a boolean field in category to indicate whether category could be selected or not (typically only leaf nodes are selectable, but in some cases categories represent generalizations). I would go ahead and create a category_translation table as a child of category that contained the text fields from category plus a locale; the text in category would be the default if there were no appropriate locale-specific record. Why put off until tomorrow what you should be done today? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Darius Jazayeri Sent: Tuesday, April 17, 2012 1:01 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements Yes, every time we've used Type in OpenMRS so far has been singular, and it also implies that the application may provide type-specific behavior. (AllergyType, ActiveListType, EncounterType, OrderType, PersonAttributeType, etc.) To me "category" is more intuitive for letting something have multiple categories, and not implying as much behavior as "type" might. And it's less likely to create confusion with our existing *Types. Other naming suggestions are welcome though. -Darius On Tue, Apr 17, 2012 at 9:38 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: Sounds good. What separates category from type? Is it just that we don't want to think of some things being multi-typed? -Burke On Tue, Apr 17, 2012 at 12:21 PM, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> wrote: I'm trying to find an approach that will provide us some code reuse, and not slow down the reporting module's development too much. I think the use case for tags is sufficiently different from what reporting needs that we shouldn't try to shoehorn them into the same thing. Also, I think that "category" fits better than "type" for what we're talking about in reporting. So, perhaps we can evolve towards having two modules that provide: 1. tag/label * folksonomy-style, whose value is just a String * just needs a single object_tag table * Supports trivial creation, like addTag(Object, String) * Do we need a "boolean shared" which indicates whether it's only visible to the creator or to other users too? 1. category * pre-defined, whose value is an OpenmrsMetadata * needs a category table and an object_category mapping table * eventually supports localization a la metadata-localization I feel like the first pass at the "category" module code can get written in the reporting module for convenience now. But I hope we can code review that and pull it into its own module before releasing it within reporting... -Darius On Tue, Apr 17, 2012 at 5:05 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: On Tuesday, April 17, 2012, Darius Jazayeri wrote: For the record, I'd be fine implementing this in a mode and calling it something other than "tagging". @Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType). Label is synonymous with tag; in fact, I've often thought that we might choose (as Atlassian did) to use the term "Label" in the UI in place of "Tag"... so, please don't use label. An alternative term for type would be "category" -- both are predefined groupings. Since we already have a precedent for these, using "type", I would favor either continuing it. I would also prefer that we follow the convention of singular vs plural for consistency. The only plural we've used is users, because "user" is a reserved word in SQL. The fact that you want to assign multiple is independent of the object itself. More than anything, I'm trying to promote consistency, both for users' and developers' sakes. In this case, avoiding a question like "why do I have to predefine tags for reporting when I don't predefine my tags anywhere else.". As I mentioned earlier, if we can model as way to control tag creation privileges per domain object, then Mike may find tagging a valid option (limiting who can create new tags as opposed to creating a separate tag management screen where tags must be created before they can be used). -Burke -Darius On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: Why not create report_type and allow reports to have more than one type? -Burke On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many. From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Burke Mamlin Sent: Monday, April 16, 2012 11:30 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements In that case, why not follow our convention of using "type" to create pre-defined categories for things, saving tagging (across OpenMRS) for user-driven folksonomies (i.e., leave tags to function like tags in blogging or labels in Confluence/JIRA)? -Burke On Mon, Apr 16, 2012 at 9:17 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: I agree with Mike that we may be talking about two different use cases -- one Burke's folksonomy and the other a tool for subsetting large lists for use by a module. My use cases are more like Mike's -- identifying which locations are labs or which locations have personnel managed by this instance of HR; with the divorce between providers and users, I think we'll see more tagging of providers for the roles they perform (or use of attributes for this purpose, which is equivalent as I've previously noted). I don't think Andy will pee in his pants if we use a concept for these purposes. From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Michael Seaton Sent: Thursday, April 12, 2012 9:23 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements Thanks Burke, I agree that we are close - I like your suggestions, but I think we are envisioning different use cases. My primary concern is not in supporting a folksonomy, making it easy ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> 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]
