Most of us are aware of the problem. If I tag this post ‘web2.0’ and you monitor Technorati for the tag ‘web20’ then we’re sunk. You’ll never find me. If I tag a webpage on del.icio.us as ‘hacks’ and you monitor the page for ‘hack’, you may never see it. These tags are virtually synonymous, but a computer can’t tell that.

Enter Tagging, a new Ning app designed to solve this very problem. The app stores groups of virtually synonymous tags (or TagGroups) that are defined by the community and provides easy access to them via both XOXO and JSON(P) APIs. With space to clearly define and describe TagGroups and a coComment catch-all discussion system the community solves their own problem by defining for the system what tags mean the same thing.

For more information see the Tagging About Page.

Back when I started using Ning to create Commentosphere I wrote a review of the service. I have since had much more experience in working with the tools provided by Ning and there have been some improvements and so this is an update on my previous review.

Language Support
To the best of my knowledge Ning still only supports PHP and XNHTML. While they expect to support more languages, for now if you don’t like PHP you won’t like development on Ning. Their PHP support, however, is top-notch. Full PHP5 support with numerous extensions installed and many Ning-specific components that just make coding easier (automated comment system, Gmail support, etc). Having previously only worked with servers supporting PHP4, just the PHP5 support seems like a miracle: code is cleaner and I can use some of those nice OOP features I’ve been reading about for ages.

The Content Store
The content store may still be hard to get into for a coder used to SQL, but once you get your head around it, it can be easier to use in some ways. For example, there are some default fields (title, description, contributorName, createdDate, updatedDate) which, if used correctly, can make transferring code between apps easier. Built-in support for tagging objects means you no longer have to have your code manage (sometimes complicated) many-to-many tables for the relationships between tags and content.

• All query filters still behave like an AND operation, but this limitation can often be overcome through code design. While the lack of a union (OR) operation can be painful to get around and would be very welcome, it is not a crucial thing in many apps.
• There is still no proper pattern matching, but this too can be partially overcome by storing dummy fields that have appropriate characters (especially non-alphanumerics) replaced by spaces and using their full-text ‘like’ operator. Not the ideal solution, but workable.
• There is still no way to change the owner of an object, but this is not the biggest problem and it seems Ning is moving towards providing API-style access themselves.
• The OOP-style of returns still inhibits sorting to some extent, but not nearly as much as I originally feared. SQL-returned arrays are often difficult to merge and sort themselves, and XN_Content objects on Ning are not unsortable, they just require self-written sorting functions. Merging query results is not a common operation anyway.
• The Content Store has been significantly speeded up. While mass operations begin to bog, or even freeze, when you deal with volumes approaching 100 objects, at least it is fast enough for some mass-updating operations.

Other Considerations and Conclusions
Multi-user development is still basically impossible on Ning. This is probably the feature #1 on my list of things I wish they’d add. The License problems are annoying (there’s a lot of good GPL code out there I’d like to use) but not fatal.

While Ning has not yet fully rectified my main initial points (speed content store to enable large scale importers, group development, pattern matching, better documentation) I have found that some of these points are mitigated as you get used to the service. While the speed limitation on the content store are annoying, they can be got around if you take data in smaller chunks. The documentation is not the greatest, but it is getting better, especially with the advent of the Ning Tech Blog. Group development is definitely my #1 request at this point.

JScripts is a new Ning app of mine for hosting JavaScript includes. The benefits of a semi-centralised location for hosting JavaScript APIs/hacks (from the FreshTags system to the prototype framework) are many, but the greatest ones are (1) it makes it easier for us to find ones others have written (2) browsers can then cache the same JavaScript for use across sites. I have put my FreshTags system on the app, but will also keep it hosted in the other location for now. This blog now includes the file hosted on JScripts, however.

JScripts (and its parent app, FileSS, which I also wrote) has a coComment-integrated comment system and also integrates features from Sweeties. There are RSS feeds for new scripts (which can be filtered by tag, user, and search query) and for comments on each script.

Yes, I know, another post on a Ning app of mine. Wrinks is an app for the creation/management of webrings, blogrings, linkrolls, and blogrolls. Ring/roll creators have full power over what sites are members of their wrink and wrinks can be embedded in web pages using either JavaScript or PHP (depending on your hosting situation) as either webrings or blogrolls. The service aims at being a sort of ‘social blogrolling’ system. The first person to add a site to the system has control over that site’s metadata (title, description, feedurl, etc.).

Traffic data is stored for each Wrink and wrinks can be browsed by tag, sorted by traffic number. These lists of wrinks can be syndicated via either RSS 2.0 or JSON(P). Each wrink can also be retreived via JSON(P) for custom inclusion in webpages.

Wrink rolls can also be filtered by tag. Each site on a roll has tags, and if &tag= is passed to the wrink, only sites matching that tag (or tag intersection) are returned. This opens the way for the possibility of filtering blogrolls by tag.

No, it’s not a new service provided by Google — it’s a Ning app built on the Google Search API. The functionality is simple. You feed Google Related Pages a URL, and it gives you back a list of related webpages. The data is collected using Google’s ‘related:’ operator. I have found in tests that it gets pretty good results when used on popular pages, but not as well when used on less popular ones.

So what is the point? Why use this instead of just doing a ‘related:’ search on Google? Isn’t this just a nicer interface to something we could already do? Not quite. You see the app also generates RSS 2.0 and JSON(P) feeds of the results. Ultimately that is the point. Results can be integrated into pages, such as blog sidebars, or watched in feedreaders. Because the data is all in the Ning app, other formats will be easy enough to add if people want them.