@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]> 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]] *On Behalf Of *Darius > Jazayeri > *Sent:* Tuesday, April 17, 2012 1:01 PM > > *To:* [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]> > 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]> > 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]> > 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]> > 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]> 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]] *On Behalf Of *Burke > Mamlin > *Sent:* Monday, April 16, 2012 11:30 AM**** > > > *To:* [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]> 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]] *On Behalf Of *Michael > Seaton > *Sent:* Thursday, April 12, 2012 9:23 PM > *To:* [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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > > ** ** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<[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]
