It feels like it was weeks ago, but we discussed this on IRC today. I would propose that (assuming this is done in reporting soon, which I think is Mike's intention): * Reporting implements the "labeling with predefined types" version of this * Before releasing that in the reporting module, we take a close look at the API. If it's actually suitable for all, then we should pull that into a "tagging" module, which reporting can depend on.
This should let reporting build this functionality quickly, while giving us a shot at making a reusable tagging module. -Darius My final comment there was that we should implement the API support for labeling/tagging in a "tagging" module. On Thu, Apr 12, 2012 at 9:25 PM, Burke Mamlin <[email protected]>wrote: > I would like to leave the door open for tags/labels to be used as > folksonomies (just like we see in blogs, Confluence, JIRA, GMail, etc.). > While tagging can surely be used as a means of categorizing (e.g., the way > we tag tickets for our reporting sprint), they are not limited to that use. > > If there needs to be a predefined pool of categories within which objects > are grouped, then use "categories" (or, to follow convention, "types"). > Assuming we can define tagging permissions at a granular enough level > (i.e., by object) and control creation vs. usage with different > permissions, then implementations could adjust permissions to meet their > needs (admin-only-tagging-of-reports vs. > anyone-can-tag-reports-but-only-with-tags-created-by-admins vs. > anyone-can-tag-reports-with-anything like in JIRA). > > If we can meet all our needs with tagging, great; however, if we start > programming in assumptions that tags can't be created on the fly by someone > with the right permissions, then we're either losing the folksonomy options > or creating tagging that will behave differently depending on where you are > within the application. > > -Burke > > On Thu, Apr 12, 2012 at 9:22 PM, Michael Seaton <[email protected]> wrote: > >> ** >> 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 [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 >> > > ------------------------------ > 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]
