This sounds good to me too. The name category makes sense. I'm likely
to just code this up in a separate module that reporting can depend
upon, rather than do it within reporting, as the legwork to do so is
minimal extra effort, assuming we can come to a consensus.
For a module ID, what do you all suggest? metadatacategory?
categorization?
Mike
On 04/17/2012 01:01 PM, Darius Jazayeri wrote:
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?
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] <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]> 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
<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]
