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? > 2. 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 > _________________________________________ 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]
