If we make tags concepts, it will conflict with (actually, essentially eliminate the possibility of) allowing tags to be a folksonomy, since we don't want (I'm sure Andy would agree) to treat our concept dictionary as a folksonomy. The intent of making tags a folksonomy (meaning that they can be created/added/removed much more easily, don't require definitions, and would likely be available to more users) was to leave the door open for tags to be creatively used by users as well as admins (e.g., let a doc tag her patients or her patients' problems how she wants).
For these reasons, I would not favor making tags into concepts. I don't want users to have to seek approval to make a new tag, nor do I want a chorus of users creating concepts ad hoc. -Burke On Thu, Apr 12, 2012 at 4:43 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > 1. I think we are in agreement that the relationship between tags and > objects is many to many, so we are looking at something like: <object> -- > <object tag map> -- <object tag>**** > > We could move toward either (a) having all object tags in a single table, > per my understanding of Wyclif's proposal, or (b) incorporating tags into > the new attribute paradigm as a multi-valued attribute of the object.**** > > ** ** > > 2. If everyone is agreed that tags may sometimes have to be translated, > then I say they should be concepts, which would give them a name and a > description and the ability to be translated. It would also make it > possible to use them as "module parameters" through concept_map. Concepts > also bring the power of concept sets; the tag widget could display a > hierarchical selection of tags and descriptions starting at an identified > set; a configuration parameter could determine whether an "add new tag" > option would be displayed (although that would not override the lack of a > privilege); another configuration parameter could determine whether a > non-leaf node could be selected.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Michael > Seaton > *Sent:* Thursday, April 12, 2012 2:44 PM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism > for tagging / categorizing reports and other reporting elements**** > > ** ** > > Here is the approach I proposed on the ticket below (generalized for > OpenMRS rather than specific to reporting). To answer your specific > questions: > > *Are tags simple Strings or objects (with uuid? with id?)?* > > They are Objects (specifically OpenmrsMetadata), but can look like / act > like Strings in practice (eg. in a UI). The main reason for making them > metadata is so that they can sync between instances and so that we could > potentially add a translation layer on top of them (eg. metadata > localization). We could also add additional metadata around them like > "these tags are appropriate for Locations. these are appropriate for > Reports") > > *Can users (with permissions) simply create new tags are is tag creation > separate from assignment?* > > Tag creation would be separate from assignment in this model. Permissions > for tag creation and tag assignment would be distinct. > * > Do we need to support localization of tags? If so, who is translating > them?* > > Yes. The same person will translate them as would translate any other > piece of OpenmrsMetadata object (which is currently not possible, but would > ultimately be done by an end-user in the UI). > > *Do we add tags as a property of OpenMRSObject?* > > We could do, but I would not imagine so. This can always be added later > on if desired. For now, I am proposing a TagService which would allow you > to get the tags for an Object on demand. > > *Design below:* > > Tag extends OpenmrsMetadata { > Integer id; > String uuid; > String name; > ... > } > > tag ( > id int(11) primary key, > uuid char(38) not null, > name varchar(100) not null, > ... > ) > > openmrs_object_tag ( > openmrs_object_uuid char(38) not null, > tag_id int(11) references tag.id > unique key definition_tag_unique_key (definition_uuid, tag_id) > ) > > TagService { > > List<Tag> getTagsForType(Class<? extends OpenmrsObject> type); > List<Tag> getTags(OpenmrsObject object); > > // Standard crud methods > Tag getTag(Integer id); > Tag getTagByUuid(String uuid); > List<Tag> getAllTags(); > Tag saveTag(Tag tag); > void purgeTag(Tag tag); > } > > Mike > > > > On 04/12/2012 01:31 PM, Burke Mamlin wrote: **** > > +1000 for having at least some fundamental agreements on our approach to > tagging (e.g., wiki page <https://wiki.openmrs.org/x/cgM3AQ> and > TRUNK-2284 <https://tickets.openmrs.org/browse/TRUNK-2284>), so that we > don't end up with dealer's choice on what tags mean across OpenMRS. There > are many potential places for tagging through OpenMRS and modules.**** > > ** ** > > Can we discuss this on a design call or on this list? As long as we align > on these things, we can change our minds later and have a clear path to > refactor.**** > > - Are tags simple Strings or objects (with uuid? with id?)?**** > - Can users (with permissions) simply create new tags are is tag > creation separate from assignment?**** > - Do we need to support localization of tags? If so, who is > translating them?**** > - Do we add tags as a property of OpenMRSObject?**** > > Cheers,**** > > ** ** > > -Burke**** > > ** ** > > ** ** > > On Thu, Apr 12, 2012 at 10:14 AM, Roger Friedman (Commented) (JIRA) < > [email protected]> wrote:**** > > **** > > ****Roger > Friedman<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=r.friedman>commented > on [image: > New Feature]REPORT-49 <https://tickets.openmrs.org/browse/REPORT-49> **** > > *Add a mechanism for tagging / categorizing reports and other reporting > elements* <https://tickets.openmrs.org/browse/REPORT-49> **** > > I agree that more translation mechanisms need to be available for > metadata. I was somewhat involved in the GSOC project. It tries to handle > translation within the existing data structures, but the result is that > text fields can no longer be sorted, I think problems like this are why it > hasn't been introduced even though it worked to specs. **** > > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators<https://tickets.openmrs.org/secure/ContactAdministrators%21default.jspa> > . > For more information on JIRA, see: http://www.atlassian.com/software/jira > **** > > ** ** > ------------------------------ > > 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]
