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