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 for users to create lots of tags on-demand, but > for administrators to create a well-defined set of categories that can be > used to better organize a library of metadata. I'm certainly not opposed > to have a nice, easy, and intuitive UI :), but I do want to make sure that > your use case of having doctors tagging their patients and my use case of > having a subset of reports categorized as "Data Quality Reports" should be > met by the same solution. As long as these goals overlap and don't clash > with each other, I'm happy. > > I would agree with Darius that supporting or not supporting on-the-fly > creation of tags seems like a UI concern, and may be something you want to > change depending on the user or the type of object being tagged. And > although I like your idea of having String-based API methods > (addTags(object, String[] tags), it is not 100% clear to me how this meshes > with our eventual support of localized tags - are the string names you pass > in for the user's current locale, the system default locale? I think I'd > rather we leave these methods off of the API for now until we figure out > whether it can be compatible with localization. > > I agree that tags should be unique. I don't think tags should be overly > restrictive as to what can be in the names, but I'm happy restricting the > use of things we commonly use as delimiters etc - namely commas, pipes, > semi-colons, dollar-signs, curly braces, and the like. I think spaces in > tags should absolutely be allowed. > > Thoughts? > Mike > > > On 04/12/2012 04:25 PM, Burke Mamlin wrote: **** > > Okay. I think we're close. **** > > ** ** > > Do we really want tag creation and assignment to be distinct operations? > I would much rather let tags function as a folksonomy, created ad-hoc by > users to meet their needs than to have a pre-defined pool of tags that I > could use. For example, imagine if you could only use existing labels in > JIRA and, if you wanted to add a new one, you would have to go to a label > management page & define a new label before you could return to your ticket > to apply it. Yuck. While I suppose supporting basic CRUD for tags is > okay, the folksonomy approach would suggest API methods like addTag(object, > tag).**** > > ** ** > > Could the API be more supportive of tags as strings and provide methods > using Tag objects for sync operations? For example:**** > > String[] getTags(object);**** > > addTags(object, String[] tags);**** > > removeTags(object, String[] tags);**** > > ** ** > > // and then for the few (sync) who needed IDs or UUIDs**** > > Tag getTagByName(String tag);**** > > ** ** > > Instead, can we follow the conventions of Atlassian labels?**** > > - *Tag uniqueness is defined by the string value* (name in your > model). We can use id/uuid under the hood for synch support; however, you > should not be able to create two "foobar" tags with different id/uuid.* > *** > > > - In the database, we would make tag.name unique.**** > - If we ever add localization of tags, then the uniqueness would be > enforced within a locale and we would never show tags in multiple > locales > at once.**** > > > - *An object can have any number of tags, but cannot have duplicate > tags* (I think you meant this by your object_tag's unique constraint & > just forgot to change the word "definition" to "object").**** > > Can tags have spaces in the names? Atlassian has chosen not to include > spaces to make their token input & creation easier (there's no ambiguity > whether "HIV anemia" is one or two tags (for Atlassian, it's always two > since spaces divide tags). On the other hand, I've seen JQuery token > input examples <http://loopj.com/jquery-tokeninput/> that allow for > spaces by using choice lists for tags, but I haven't seen one that combines > this with on-the-fly tag creation. I suppose you could use commas to > separate tags.**** > > ** ** > > Along the same line, what are the specs for a tag name – what are the > allowed characters & how long can they be? You've suggested 100 chars as > the max length, which is fine by me. Which characters are valid? If we > allow spaces, then we should probably reserve comma as a delimiter. Do we > want quotes or non-printable characters in tag names? It's probably better > to avoid over-restricting, but it's probably at least agreeing on some > restrictions (e.g., no comma, no backslash, no non-printable characters).* > *** > > ** ** > > Cheers,**** > > ** ** > > -Burke**** > > ** ** > > On Thu, Apr 12, 2012 at 2:44 PM, Michael Seaton <[email protected]> wrote:** > ** > > 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 > 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]
