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.
o In the database, we would make tag.name <http://tag.name>
unique.
o 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]
<mailto:[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 <http://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]
<mailto:[email protected]>> wrote:
Roger Friedman
<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=r.friedman>
commented on 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
<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]
