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