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? >> 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 >> > > ------------------------------ > 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]
