Content Tagging
Implement a tagging system available for content. Use the search index as a common location for content to be tagged.
AdminMark Dexter
(Admin, Joomla!)
shared this idea
27 comments
-
Josh
commented
Tagging has now been released for Joomla 3.1
http://www.joomla.org/announcements/release-news/5494-joomla-3-1-0-stable-released.html -
Aqua CS4 commented
i still waiting for this feature.
-
David Goldstick commented
Please consider this idea modeled after Google Docs. It combines both simplicity and flexibility that Joomla currently lacks:
Google has found a new way to decide the eternal dispute between fans of folders and tags - invented a new concept - "collections." Google Docs developers say that these collections combine the advantages of tags and folders. You can add a document to different collections and store collections hierarchically, just like folders.
Discussion here: http://forum.joomla.org/viewtopic.php?f=575&t=636602&p=2558211
-
Node-0
commented
@Nicholas Dionysopoulos
I totally agree about needing to set the tags implementation on a solid architectural foundation and I'm going to need to take a cold shower after writing what I'm about to write but...
I would like to take the time to say that the tags aspect of a CMS is more than simple labels, a tags system could simply have tag words and phrases as discrete fields, but if only the following where there as additional fields, amazing things could easily materialize...
A "rating" field, A "rank" field, A "like" field, A "vote" field, these could all be relatively small and unobtrusively tucked away into the tags many to many table. I know it looks like heresy from a "carefully thought out" approach.
It reeks of amoeba-scale intelligence, of a wishful "wordpressian" coup d'état (a coup which I do NOT harbor in any way shape or form), of possibly horrible crimes against sanity (in design).
On the other hand... We don't have to use it. The fact that such fields be in the table and related to all entities in Joomla would open the "mindedness" of Joomla's design and allow people who have no wish to implement a full component-scale solution, to implement a plugin-scale solution.
Sometimes I see new feature additions to Joomla as similar to a fiercely
evolution-resistant species, whereby old traits are very strongly conserved and any new possibilities are simply born into an environment too hostile to foster any new explorations.I do not mean to make it seem that I want "every feature under the sun" in Joomla, rather what I mean to say is that the "potential" to experiment by allowed by some small provision.
In my opinion, I think a JSON-clad (and API accessible) tinytext field in the tags many to many table would be an excellent way to enable that "experimentability" without having to "debate every last permutation" of a tags system.
I also do NOT mean to imply that either you or anyone else here was engaging in such a debate.
I was simply expressing what I'd like to see, a "little bit", perhaps a "tiny bit" provision to let in a little chaos, so that maybe just maybe someone out there might implement something really cool in a plugin or module, without having to march through component development boot camp.
It wouldn't ruin Joomla to provide a meager "umph" of room 'somewhere' in a tightly integrated table, an "umph" of "Here's a JSON workbench, go nuts!"
Is this a proposal for the primary tagging mechanism, of course not, far from it. This is a proposal to "let in a little light" so that maybe someone out there with a bright idea, could play with that idea in a non-threatening (architecturally speaking) way.
I said I would need to take a cold shower after uttering such heresy, so off I go...
-
Nicholas Dionysopoulos
commented
Comma delimited fields are very ineffective. First, MySQL doesn't natively support them (for a good reason). Doing a full text search on the field is not only slow, it is also very error-prone. Therefore, you have to implement a manual post-filter to the full text search which is memory intensive and dead slow. Would you like to see a feature which completely kills performance?
The architecturally sound way to do that is to implement many-to-many relationships. One table holds the tags as (id, tag). Another table holds the many-to-many relationship, e.g. (article_id, tag_id).
Please remember that multi-value fields ARE NOT designed for searching and indexing. Just because a whole generation of users is abusing that sorry excuse of a database called Microsoft Access doesn't mean that they are doing it right.
Also remember that XML is not a database. It's a data description metalanguage. You can't "search" data in an XML file. You have to load it, parse it, convert it to an in-memory object format and then apply your search algorithms. Therefore, the data dump representation need not be the same as the structure of the working data. Think about a MySQL dump. Can you use it to efficiently search for records. Not by a long shot, you can't.
-
MikeFromHC
commented
"Nicholas Dionysopoulos
It's about data normalization"
Everything you say is true and I suspect that the nested category solution will have problems because they use a delimited field to store the hierarchy (Animals/birds/ robins)
But tags could be handled in a many to one relationship and displayed as comma delimited, MSFT Access does this with "Multivalued" fields.
Note also that Pick uses multivalued fields to great effect, so does XML. -
Node-0
commented
Tags are vital to the future of Joomla.
We need a robust tags API and pervasive tags support for ALL
Joomla entities (not just content), we also need a fast tags indexing
system alongside a content indexing system.The above features are essential, yet I'd like to suggest an "expansion oriented" feature set for the tags system. One that would enable Joomla
to adapt and grow in unexpected directions with the mere addition of a few
fields.
I'd like to see an indexed field for adding a JSON string for custom data associations.This could be a Tinytext field for a small footprint.Please Note: When I say "indexed" I'm referring to the MySql field convention and not some other type of "indexing system" much as one would be useful for Joomla, just FYI...
You'd be surprised how much functionality a programmer could realize with a 255 character long "anything goes" JSON block, a whole lot of cross referenced data could be stored and utilized to bring very powerful applications to Joomla.
As it stands, I find myself taking over the X Reference field in the content table for storing custom JSON data, and that's more like a hack than I'd like.
Please, I'd be happy with an indexed, cross referenced tinytext field, with API implemented programmatic access, a set of methods for basic access would be awesome.
-
Michael
commented
Yes Tagging is very important and Useful, also API for 3rd-Party extensions...
-
getimo
commented
Yes, tagging id definitely the most important thing. Give us an API for 3rd Party extensions too! Imagine how jReviews and Jomsocial would benefit from that.
-
Gerry Cervenka
commented
Both front- and back-end access to applying tags and creating new tag definitions would benefit collaborative websites. Authors are often best suited to select or add tags, not site administrators -- esp. for specialized content. Allowing only certain User level access to creating tags would keep the tags list from becoming unmanageable. And checkbox lists work great, so the Author is presented with terms instead of having to key them and possibly introduce typos, which would render the tags search less effective.
-
newart
commented
What discussing or commenting... ? It's natural to finish the work started in 1.6 version about categorization! We have a nested one but Joomla lacks of a real tagging system. So I think Joomla 1.6 after ACL & nested categories must get the best tagging system than ever. The focus in the future is still on contents - J is a CMS first of all - and contents deserve tags and tags. J deserves a showing / searching contents by tags because i's just a different approach than our actual categorization system. Sorry but the nested one is already old and little flexyble. Joomla needs a complete new and integrated system for managing contents... the content is the king! Please remember...
-
Provia
commented
It's important to have a tag / keyword system perfectly integrated into the core. We have now unlimited "vertical" categories but no "horizontal" ones. The keywords are like a category but also a special quality of content. It's very important to see what tagged in an article and how to search that tag in our joomla site, very important!
-
Josh
commented
Agreed!
-
Gabe Wahhab
commented
Tagging should be integrated into the Joomla core library not just for content. So developers can use a central tagging system. What good is it if i create a tag in calendar component and create the same tag in a content component but when i click the tag it only shows results from one or the other. It should be centralized and give the integrator the option to choose how they want ti to work.
-
Krycek.lx
commented
Thanks Nicholas for this explanation. Understand that I'm also developer (even n00b I'd say) and that I understood those. I also do know what means "developing for users" when users don't even know what they really want.
Now, to go further on this, why isn't it possible for J! to have some tags handled by a DB table (say 1=chocolate;2=candy) and thus used for tag browsing articles ? Then use the same articles tags for meta-tags (like "chocolate, candy" ?
That was my point (though I'm not very clear when speaking in english) : reversing the purpose of the tag in J! article editor and fulfilling meta tags need the same way. Can't the most do the least ?
(this is a non-rhetorical question) -
Nicholas Dionysopoulos
commented
It's about data normalization. In the meta tag field your tags would be stored as "international, stories, foobar" or "International; STORIES fOoBaR" and search engines would understand them equally. However, if you want to *search* for those tags you have to query your database with a case insensitive regular expression which can handle the different separators you might be using and which is slower by a whole order of magnitude than an integer search (the normal search if you use a table of tags). As a result, your idea would make Joomla! slower than a snail making its way through fly paper.
And, no, daydreaming IS for developers and I have personally proven it time over time the last four years. However daydreaming is one thing and developing something is another. We can develop anything the user asks, but the problem is that we will develop *exactly* what the user asks. So, if you ask for a cumbersome, inconsistent and useless feature, we can develop it. But then you will start whining that this feature was not what you thought it would be, because you hadn't thought of a, b, c and d. So, the job of a real developer is to foresee those issues and warn you whenever you're daydreaming something that we know you won't like if it's implemented. Not trolling, just laying down the harsh truth of 10+ years of writing software used by other people ;)
The bottom line is that you have mixed the two "tag" things in your head. Meta tags' (properly called "keywords") sole purpose in this life is to hint search engines about keywords on the page. They were invented long before Google and the modern sophisticated search algorithms. They may be obsolete now, but they're still in the HTML spec so we have to have a way to define them should we need to.
Content tags are used as a secondary, many-to-many organization of the content items. The classic section-category-article or the newer nested category-article scheme only allows a tree-like structure, i.e. a content item can belong to exactly one category. Tags allow you to assign a content item to multiple "tags". So, many tags can belong to a single content item and multiple content items can belong to a single tag. This is what Drupal's taxonomy and WordPress' multiple categories per post do.
As far as the interface goes, please take a look at how K2 tackles this in the most intuitive way possible. Content are upfront and very easy to attach to an item, whereas the obsolete meta tags are tucked away from view.
-
Krycek.lx
commented
@Nicholas : I'm not "not listening to him". I say that from DB point of view, having the user filling twice fields related to tags will have him wonder why.
Daydreaming is the thing of users... should I understand it's not of developers ? :) (not trolling)
-
Nicholas Dionysopoulos
commented
@Krycek.lx Daydreaming is one thing, developing a feature is another. The meta tags field is a free text field. As a result, doing search operations against it (which is the primary reason to use a content tagging system) will be dead slow and unreliable. Stefan is right when he says that this would create a mess out of your data. Listen to him.
-
Krycek.lx
commented
@Stefan : well I'd think otherwise. Meta-tags are tags for the content displayed. In what are they different from what you would tag your documents ?
Having separate fields for the same semantic but voth purpose isn't convenient, nor datase oriented (redundancy). Point isn't to format those tags within the field but on display :
- creation of SEF Tags within HTML (invisible),
- creation of links to Joomla! internal search which will fetch within article.metatag field database.I ain't asking for a specific feature to be implemented, just orientating the debate towards the possible solution, so that maybe some component may fetch through this DB.article.metatags to complete other available modules already formatting those tags for display. (we're so close !)
-
Stefan | dpdk
commented
@Krycek.lx; Besides the rumors that the meta-tag field (it's function) is no longer relevant for Google indexing, shouldn't approve that this data inputfield is used for other purpeses than it's intended to be.
Then you creating a mess of your data!
BTW, you would have to build some logics for seperating the normal Meta-data from the Tags-data. So it won't conflict with the Tagging functionalities, when this data is being processed.
