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