Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

classic Classic list List threaded Threaded
24 messages Options
12
Burke Mamlin-2 Burke Mamlin-2
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

+1000 for having at least some fundamental agreements on our approach to tagging (e.g., wiki page and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: [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 and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira





[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

In reply to this post by Michael Seaton

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 2:44 PM
To: [hidden email]
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 and 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) <[hidden email]> wrote:

Roger Friedman commented on New FeatureREPORT-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Locations and Concept Names are the only other taggable objects.

The "name" on those currently is limited to 50 chars.

We're not doing any of the restrictions at the ui or api level.
See http://demo.openmrs.org/openmrs/admin/locations/locationTag.list

And locations don't let you add tags: http://demo.openmrs.org/openmrs/admin/locations/location.form?locationId=3

Ben

On Thu, Apr 12, 2012 at 4:43 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 2:44 PM
To: [hidden email]
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 and 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) <[hidden email]> wrote:

Roger Friedman commented on New FeatureREPORT-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Burke,

Gmail's UI for adding labels to a conversation is my favorite UI for tagging, with an autosuggest for existing options, and it show you when you're about to create a new one.

Allowing on-the-fly creation of tags seems like a UI concern, doesn't it? Though I think we should have addTag(Object, Tag) and removeTag(Object, Tag) anyway.

If I assume that we do want to eventually localize tags, I don't like the idea of letting people interact with them at the API level as if they were just strings, unless we add locale to it. E.g.
addTag(Object object, String tag, Locale localeForTag)

In the initial implementation that locale can be ignored, but if we know we're going to be localizing, I'd rather not let people use an ambiguous String.

-Darius

On Thu, Apr 12, 2012 at 1:52 PM, Ben Wolfe <[hidden email]> wrote:
Locations and Concept Names are the only other taggable objects.

The "name" on those currently is limited to 50 chars.

We're not doing any of the restrictions at the ui or api level.
See http://demo.openmrs.org/openmrs/admin/locations/locationTag.list

And locations don't let you add tags: http://demo.openmrs.org/openmrs/admin/locations/location.form?locationId=3

Ben


On Thu, Apr 12, 2012 at 4:43 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 2:44 PM
To: [hidden email]
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 and 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) <[hidden email]> wrote:

Roger Friedman commented on New FeatureREPORT-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

In reply to this post by Friedman, Roger (CDC/CGH/DGHA) (CTR)
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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 2:44 PM
To: [hidden email]
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 and 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) <[hidden email]> wrote:

Roger Friedman commented on New FeatureREPORT-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

In reply to this post by Darius Jazayeri-3
Darius,

I'm equally in love with the GMail tagging UI, including the way they've accomplished single- & multi-selection in one simple, intuitive interface (tap on label for single select, use checkboxes for multiple select)… brilliant!

I agree these could be UI issues.  I'm just trying to push against the standard practice in OpenMRS to make things harder (more steps) and promotes the creation of invalid (incomplete) objects via empty constructors.

-Burke

On Thu, Apr 12, 2012 at 5:29 PM, Darius Jazayeri <[hidden email]> wrote:
Burke,

Gmail's UI for adding labels to a conversation is my favorite UI for tagging, with an autosuggest for existing options, and it show you when you're about to create a new one.

Allowing on-the-fly creation of tags seems like a UI concern, doesn't it? Though I think we should have addTag(Object, Tag) and removeTag(Object, Tag) anyway.

If I assume that we do want to eventually localize tags, I don't like the idea of letting people interact with them at the API level as if they were just strings, unless we add locale to it. E.g.
addTag(Object object, String tag, Locale localeForTag)

In the initial implementation that locale can be ignored, but if we know we're going to be localizing, I'd rather not let people use an ambiguous String.

-Darius


On Thu, Apr 12, 2012 at 1:52 PM, Ben Wolfe <[hidden email]> wrote:
Locations and Concept Names are the only other taggable objects.

The "name" on those currently is limited to 50 chars.

We're not doing any of the restrictions at the ui or api level.
See http://demo.openmrs.org/openmrs/admin/locations/locationTag.list

And locations don't let you add tags: http://demo.openmrs.org/openmrs/admin/locations/location.form?locationId=3

Ben


On Thu, Apr 12, 2012 at 4:43 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 2:44 PM
To: [hidden email]
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 and 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) <[hidden email]> wrote:

Roger Friedman commented on New FeatureREPORT-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

In reply to this post by Burke Mamlin
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira





[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

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 <[hidden email]> 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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira





[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

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 <[hidden email]> 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 <[hidden email]> 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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:
Roger Friedman commented on New Feature 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira





[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

In reply to this post by Michael Seaton

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:

Roger Friedman commented on 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


 

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:

Roger Friedman commented on 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


 

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:

Roger Friedman commented on 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


 

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list

Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Why not create report_type and allow reports to have more than one type?

-Burke

On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:

Roger Friedman commented on 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


 

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

For the record, I'd be fine implementing this in a mode and calling it something other than "tagging".

@Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType).

-Darius

On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[hidden email]> wrote:
Why not create report_type and allow reports to have more than one type?

-Burke


On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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 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 <[hidden email]> 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 and 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) <[hidden email]> wrote:

Roger Friedman commented on 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


 

 


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

 


[hidden email] from OpenMRS Developers' mailing list



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

On Tuesday, April 17, 2012, Darius Jazayeri wrote:
For the record, I'd be fine implementing this in a mode and calling it something other than "tagging".

@Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType).


 Label is synonymous with tag; in fact, I've often thought that we might choose (as Atlassian did) to use the term "Label" in the UI in place of "Tag"... so, please don't use label.

An alternative term for type would be "category" -- both are predefined groupings.  Since we already have a precedent for these, using "type", I would favor either continuing it.  I would also prefer that we follow the convention of singular vs plural for consistency.  The only plural we've used is users, because "user" is a reserved word in SQL.  The fact that you want to assign multiple is independent of the object itself.

More than anything, I'm trying to promote consistency, both for users' and developers' sakes.  In this case, avoiding a question like "why do I have to predefine tags for reporting when I don't predefine my tags anywhere else.". As I mentioned earlier, if we can model as way to control tag creation privileges per domain object, then Mike may find tagging a valid option (limiting who can create new tags as opposed to creating a separate tag management screen where tags must be created before they can be used).

-Burke


-Darius

On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[hidden email]> wrote:
Why not create report_type and allow reports to have more than one type?

-Burke


On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

I'm trying to find an approach that will provide us some code reuse, and not slow down the reporting module's development too much. I think the use case for tags is sufficiently different from what reporting needs that we shouldn't try to shoehorn them into the same thing. Also, I think that "category" fits better than "type" for what we're talking about in reporting.

So, perhaps we can evolve towards having two modules that provide:
  1. tag/label
    • folksonomy-style, whose value is just a String
    • just needs a single object_tag table
    • Supports trivial creation, like addTag(Object, String)
    • Do we need a "boolean shared" which indicates whether it's only visible to the creator or to other users too?
  2. category
    • pre-defined, whose value is an OpenmrsMetadata
    • needs a category table and an object_category mapping table
    • eventually supports localization a la metadata-localization
I feel like the first pass at the "category" module code can get written in the reporting module for convenience now. But I hope we can code review that and pull it into its own module before releasing it within reporting...

-Darius

On Tue, Apr 17, 2012 at 5:05 AM, Burke Mamlin <[hidden email]> wrote:
On Tuesday, April 17, 2012, Darius Jazayeri wrote:
For the record, I'd be fine implementing this in a mode and calling it something other than "tagging".

@Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType).


 Label is synonymous with tag; in fact, I've often thought that we might choose (as Atlassian did) to use the term "Label" in the UI in place of "Tag"... so, please don't use label.

An alternative term for type would be "category" -- both are predefined groupings.  Since we already have a precedent for these, using "type", I would favor either continuing it.  I would also prefer that we follow the convention of singular vs plural for consistency.  The only plural we've used is users, because "user" is a reserved word in SQL.  The fact that you want to assign multiple is independent of the object itself.

More than anything, I'm trying to promote consistency, both for users' and developers' sakes.  In this case, avoiding a question like "why do I have to predefine tags for reporting when I don't predefine my tags anywhere else.". As I mentioned earlier, if we can model as way to control tag creation privileges per domain object, then Mike may find tagging a valid option (limiting who can create new tags as opposed to creating a separate tag management screen where tags must be created before they can be used).

-Burke


-Darius

On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[hidden email]> wrote:
Why not create report_type and allow reports to have more than one type?

-Burke


On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Sounds good.  What separates category from type?  Is it just that we don't want to think of some things being multi-typed?

-Burke

On Tue, Apr 17, 2012 at 12:21 PM, Darius Jazayeri <[hidden email]> wrote:
I'm trying to find an approach that will provide us some code reuse, and not slow down the reporting module's development too much. I think the use case for tags is sufficiently different from what reporting needs that we shouldn't try to shoehorn them into the same thing. Also, I think that "category" fits better than "type" for what we're talking about in reporting.

So, perhaps we can evolve towards having two modules that provide:
  1. tag/label
    • folksonomy-style, whose value is just a String
    • just needs a single object_tag table
    • Supports trivial creation, like addTag(Object, String)
    • Do we need a "boolean shared" which indicates whether it's only visible to the creator or to other users too?
  2. category
    • pre-defined, whose value is an OpenmrsMetadata
    • needs a category table and an object_category mapping table
    • eventually supports localization a la metadata-localization
I feel like the first pass at the "category" module code can get written in the reporting module for convenience now. But I hope we can code review that and pull it into its own module before releasing it within reporting...

-Darius

On Tue, Apr 17, 2012 at 5:05 AM, Burke Mamlin <[hidden email]> wrote:
On Tuesday, April 17, 2012, Darius Jazayeri wrote:
For the record, I'd be fine implementing this in a mode and calling it something other than "tagging".

@Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType).


 Label is synonymous with tag; in fact, I've often thought that we might choose (as Atlassian did) to use the term "Label" in the UI in place of "Tag"... so, please don't use label.

An alternative term for type would be "category" -- both are predefined groupings.  Since we already have a precedent for these, using "type", I would favor either continuing it.  I would also prefer that we follow the convention of singular vs plural for consistency.  The only plural we've used is users, because "user" is a reserved word in SQL.  The fact that you want to assign multiple is independent of the object itself.

More than anything, I'm trying to promote consistency, both for users' and developers' sakes.  In this case, avoiding a question like "why do I have to predefine tags for reporting when I don't predefine my tags anywhere else.". As I mentioned earlier, if we can model as way to control tag creation privileges per domain object, then Mike may find tagging a valid option (limiting who can create new tags as opposed to creating a separate tag management screen where tags must be created before they can be used).

-Burke


-Darius

On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[hidden email]> wrote:
Why not create report_type and allow reports to have more than one type?

-Burke


On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

Yes, every time we've used Type in OpenMRS so far has been singular, and it also implies that the application may provide type-specific behavior. (AllergyType, ActiveListType, EncounterType, OrderType, PersonAttributeType, etc.)

To me "category" is more intuitive for letting something have multiple categories, and not implying as much behavior as "type" might. And it's less likely to create confusion with our existing *Types.

Other naming suggestions are welcome though.

-Darius

On Tue, Apr 17, 2012 at 9:38 AM, Burke Mamlin <[hidden email]> wrote:
Sounds good.  What separates category from type?  Is it just that we don't want to think of some things being multi-typed?

-Burke


On Tue, Apr 17, 2012 at 12:21 PM, Darius Jazayeri <[hidden email]> wrote:
I'm trying to find an approach that will provide us some code reuse, and not slow down the reporting module's development too much. I think the use case for tags is sufficiently different from what reporting needs that we shouldn't try to shoehorn them into the same thing. Also, I think that "category" fits better than "type" for what we're talking about in reporting.

So, perhaps we can evolve towards having two modules that provide:
  1. tag/label
    • folksonomy-style, whose value is just a String
    • just needs a single object_tag table
    • Supports trivial creation, like addTag(Object, String)
    • Do we need a "boolean shared" which indicates whether it's only visible to the creator or to other users too?
  2. category
    • pre-defined, whose value is an OpenmrsMetadata
    • needs a category table and an object_category mapping table
    • eventually supports localization a la metadata-localization
I feel like the first pass at the "category" module code can get written in the reporting module for convenience now. But I hope we can code review that and pull it into its own module before releasing it within reporting...

-Darius

On Tue, Apr 17, 2012 at 5:05 AM, Burke Mamlin <[hidden email]> wrote:
On Tuesday, April 17, 2012, Darius Jazayeri wrote:
For the record, I'd be fine implementing this in a mode and calling it something other than "tagging".

@Burke, what if we called these "labels", rather than "types"? (I.e. tags are for folksonomy, but labels are for categorization.) So far everywhere we've used type in the OpenMRS core has been singular (I recall EncounterType, OrderType, VisitType).


 Label is synonymous with tag; in fact, I've often thought that we might choose (as Atlassian did) to use the term "Label" in the UI in place of "Tag"... so, please don't use label.

An alternative term for type would be "category" -- both are predefined groupings.  Since we already have a precedent for these, using "type", I would favor either continuing it.  I would also prefer that we follow the convention of singular vs plural for consistency.  The only plural we've used is users, because "user" is a reserved word in SQL.  The fact that you want to assign multiple is independent of the object itself.

More than anything, I'm trying to promote consistency, both for users' and developers' sakes.  In this case, avoiding a question like "why do I have to predefine tags for reporting when I don't predefine my tags anywhere else.". As I mentioned earlier, if we can model as way to control tag creation privileges per domain object, then Mike may find tagging a valid option (limiting who can create new tags as opposed to creating a separate tag management screen where tags must be created before they can be used).

-Burke


-Darius

On Mon, Apr 16, 2012 at 10:35 AM, Burke Mamlin <[hidden email]> wrote:
Why not create report_type and allow reports to have more than one type?

-Burke


On Mon, Apr 16, 2012 at 12:12 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[hidden email]> wrote:

Because we're in modules and have to use either attributes or tags and only tags have allowed many-to-many.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Burke Mamlin
Sent: Monday, April 16, 2012 11:30 AM


To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OPENMRS-JIRA] (REPORT-49) Add a mechanism for tagging / categorizing reports and other reporting elements

 

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Thursday, April 12, 2012 9:23 PM
To: [hidden email]
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


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
12