9 Replies Latest reply on Mar 25, 2014 11:02 AM by NickLightbody

    Labelling (or "tagging") records

    davehob

      The application I'm currently working on has a system of "status indicators" for people records, e.g. PPL_Status_Homeless, when set to "1", indicates that this person is homeless. There are 2 problems with this setup:

       

      1. The indicators are hard-coded, and are therefore not easily variable between installations of the system. Different installations have very different requirements, and we need something more flexible to avoid a very long list of indicators.
      2. All indicators are held for all records, and either set or not. This is clearly ineffiicient, and will become more so as the no. of indicators grows.

       

      So I'm planning to have a simplified mechanism for labelling (or "tagging") records, based on the common experience of tagging blog posts, photos, etc. A global field (in an Interface table) will hold a return-separated list of all available tags ("Homeless", "Special needs", etc.). On each person's record, there will be a text field (PPL_Tags) holding a return-separated list of all tags held for each person, with the list maintained by the user simply clicking on a list of available tags, to toggle them on or off for that person.

       

      I can't see any reason why this won't give me the searching and reporting functionality that I need (e.g. "show me all homeless people", "list all people with the following tags...") - BUT, it seems so straightforward that I fear I'm missing something. If you can see a problem with this approach, I'd really appreciate your input.

       

      Thanks,

       

      Dave.

        • 1. Re: Labelling (or "tagging") records
          comment

          The conventional implementation of your suggested approach would use a field formatted as checkboxes to assign the different tags to a person. The value list of "available tags" would be using either custom values in the value list definition or  records in a dedicated table. Note that a value list cannot be based on a global field.

           

          There is no disadvantage to this method compared to what you have now - though there are some limitations to both, compared to keeping the tags in a related table, for example: a tag cannot have any attributes (such as date or reason). You also cannot produce a report of people grouped by tags.

          1 of 1 people found this helpful
          • 2. Re: Labelling (or "tagging") records
            davehob

            Michael,

             

            Thanks for this.  Your point about being able to produce reports based on tags is very pertinent actually.  So, am I right in thinking that the "proper" way to do this is to have a table of Tags, related to People via a join table ("Tag Allocations")?

             

            Dave. 

            • 3. Re: Labelling (or "tagging") records
              comment

              Yes, though there is no need to be "proper" if you are aware of the limitations and prepared to live with them...

              • 4. Re: Labelling (or "tagging") records
                RayCologon

                Michael Horak wrote:

                Yes, though there is no need to be "proper" if you are aware of the limitations and prepared to live with them...

                 

                Agreed, Michael - sort of. However, the alternatives always seem so improper!

                 

                But seriously, there are more reasons to consider placing the 'tags' in a related table than just the ability to store tag attributes and/or to group tags by people. Apart from sub-summary reporting options (which include grouping people by tags as well) there are a host of other reporting and data analysis possibilities that are either opened up or made much easier if the data is stored in that way. Plus there is the potential advantage that the parent record modification date/time/account etc won't be affected by tag changes (each tag, having its own record, can have it's own meta data fields).

                 

                I know you know all this, and its possible Dave does too. Just thought it worth expanding the list of pros for the relational option. ;)

                 

                Regards,

                Ray

                ------------------------------------------------

                R J Cologon, Ph.D.

                FileMaker Certified Developer

                Author, FileMaker Pro 10 Bible

                NightWing Enterprises, Melbourne, Australia

                http://www.nightwingenterprises.com

                ------------------------------------------------

                • 5. Re: Labelling (or "tagging") records
                  comment

                  Ray Cologon wrote:


                  there are more reasons to consider placing the 'tags' in a related table than just the ability to store tag attributes and/or to group tags by people.

                   

                  Definitely - those were only examples.

                  • 6. Re: Labelling (or "tagging") records
                    mbraendle

                    Hi,

                     

                    to shift the discussion to a more general level, the way of setting up tagging of records much depends on how much freedom the users have to name their tags, the input mode (whether directly in the database or in the Web), if users are authenticated or anonymous, and depending on the freedom users have whether an editorial process must be installed to remove garbage or not. On the Web, even a Captcha may be required to avoid tag spammers.

                     

                    For our library information system, we have tentatively setup an internal DB model that uses a table that just collects user tags, and a table which aggregates and weights them. We are however still not sure whether we will publish that for our users on the Web, given the reasons above. For the moment, our attitude is "rating yes, but tagging no". If we decide for "tagging yes", it must be very simple for both users and content administrators.

                    • 7. Re: Labelling (or "tagging") records
                      davehob

                      An interesting discussion, which has helped me a lot.  I've gone for the "proper" method, with a separate "tags" table and a "tag allocation" join table having seen the advantages, and confident that the investment of a bit of extra coding at this stage will pay off in the long run.

                       

                      Thanks again,

                       

                      Dave.

                      • 8. Re: Labelling (or "tagging") records
                        davehob

                        As a PS to this, I have documented the implementation of this over at http://filemakermisc.wordpress.com/2012/02/08/easy-toggling-of-tags/, partly as an aide-memoire for myself when I have to do it again, but also in the hope that it may be of use to others in future.  The whole exercise has been very informative - thanks again.

                         

                        Dave.

                        • 9. Re: Labelling (or "tagging") records
                          NickLightbody

                          Dave & Ray,

                           

                          Thanks for the comments on this thread and to Dave for his blog page on his approach.

                          Most of the complication here arises from the perceived need to avoid using duplicate Tags.

                          This could perhaps be simplified further if one displays the value list of the tag record as opposed to the actual tags field - since the value list obviates any need to avoid using duplicates - then use a substitution to remove the tag(s) when untagging a record?

                          Just a thought, Nick