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

_________________________________________

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]

Reply via email to