20 February 2005

XML Concepts: Tag Search Feed Management Tools

Quick tip: Newsgator Online has a tool in java converting "mail to xml": Newsgator Manager: Add a Feed: Smart Feeds : E-mail feeds



XML Tag Monitoring Tool

Monitors tag uses, last look, updates


Tags are taking off. With time, many people will have many tags that they are monitoring, actively using, and dialoging with. Tags may also go in new directions.

Let's consider, as an analogy, how links took off. With time, there were tools in the browsers called bookmarks that allowed users to organized these links. Then came webpages bookmarks that you could save, download, share, and organize into groups. These transformed into XML related products like del.icio.us and furl.

I see the same thing happening with tags that happened with links. Namely, tags are going to get saturated and, like feed content and feeds, will not only take on a life of their own, but become an obstacle to clear analysis.

This isn't to say that tags are bad. Rather, the way forward is to consider tools that will help end-users manage specifically their tags.

At this juncture, it is clear that end-users can individually track their tags using various feed monitoring tools. However, these tend to be a bit cumbersome as each tag has to be loaded as a specific feed, then individually tracked.

Also these feed-based tag-tracking systems are not really all that conducive to updates in that its hard to see what new tags have been added by simply relying on a single feed.

It is possible with NewsGator to find new content, but we're still talking about feeds that users have to individually click on to find new content. At worst, all the tags get segregated into separate feeds that the users can individually monitor in their aggregator, then pull them all together.

What I propose is way of approaching tags the same way that people have approached links: Namely, develop tools that help to specifically organize tags, and then integrate these organizationally systems into the existing XML products and platforms like blogs, aggregators, and integrate with the existing search tools like Technorati and other XML feed searchers.

To discuss further, use this tag:


LEGAL NOTICE


Creative Commons License

This work is licensed under a Creative Commons License.

You may not copy any of this work to promote a commercial product on any site or medium in the universe.

If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

Free to use for non-commercial uses. Link to this original blogspot and cite as .



Tests


I would encourage users to look at the various existing platforms and search mechanisms and see whether the current search tools could be enhanced if they had link-uri-related features also applied to feeds and tags.

Specifically, if we look at Technorati, we can see that each watch list allows users to individually track a specific search. Also, something like MyStack can aggregate these searches into a single output. More broadly, the aggregators can translate these individual searches into a consolidated approach.

In the short term, rather than re-invent a new architecture or protocol designed to specifically organize tags then integrate them into the existing platforms, users might want to see if they have occasion to change the Technorati watch-list code, tailor it to a specific new tag, then add that URI to an aggregator to see if the results display.

Also, users may wish to take the existing 2XML conversion tools [convert HTML, searches, other tasks into XML-feeds, like 2RSS] and see whether these tools can work on various searches.

For example, if you have a link from a search engine that doesn't give you an XML feed, see if there is a way to convert the search-URL from the URL-format into something that your aggregator can read, use, and display.

For example, take a URL for a .txt document, see if you can use a system to convert that .txt document URL into something that is XML-readable, then get it to display in your aggregator, then have your aggregator convert it into a new format that you choose.

Also, see if you can find new strings of terms, enter them as a tag, is see if you can find content already published that doesn't specifically have a tag, but still reports in the tag list.


Going forward


As you can see, the above challenges are not necessarily clear. Thus, I propose the following solutions to modernize the XML products into something that is likely to embrace tags just the way that bookmarks embraced links.

The idea is to make tags just as easy to find, archive, index, and incorporate into feeds as we do with webpages and links into current XML products.

Ready?


XML Tag Registry

Report and recording tags


This system can identify strings of words, translate them into tags, and then register these search groups as new tags that others can then commonly-discuss.

The idea is that content that is already published can be injected with a new tag, and others can quickly find this tag in old content.

This system would store and record tags in URL format. This would be a way to show what's changed and added since the last visit to the tag-list. Users would have the option to check all-as-read.

To discuss further, use this tag:


XML Tag Mapping

Mapping tool for tags


As it stands, there are visual mapping tools for del.icio.us tags, Flickr images. You can visually see where the items relate to each other in a visual hierarchy or maps. Kind of like the Six Degrees of Kevin Bacon game.

What's needed is something that focuses exclusively on the tags themselves, regardless whether they are words or images.

These tag mapping tools would follow the discussion for either one platform or many platforms and aggregate all the tag-discussions into a visual map. This would allow the end-user to see which nodes have taken off in terms of time.

Flickr allows users to take an image and map them in terms of both usage and where the image was taken on the blog. Del.icio.us has a link map.

The next step is to apply the wiki-concept that IBM uses which visually shows changes in a wiki, and then apply that concept to tagging.

To discuss further, use this tag:


XML Universal Search

Search all platforms with a single feed


Right now, users can go to a single platform like Mama search and search many search engines. However, there's no single system for all XML and non-XML systems.

What's needed is a platform that can search everything. Not just like MyStack which focuses on feeds that have been pinged, but everything: News, photos, blogs, search engines, websites. The system needs to look for both XML and non-XML content that may or may not be pinged into FeedMesh.

The idea is that a single feed could cross all search platforms and uses would get a single XML feed for that single, specific search that looks both forward and backward in time. This system would integrate with the existing search engines.

One search would return results which can get broken down into categories. Users can either define prior to the search-execution which categories they want displayed; or they can take the composite list, and have their aggregator assign the content into folders. In short, the foldering can be either applied at the front even of the search or at the back end as the results report in the feeds.

To discuss further, use this tag:


XML Awareness Analysis

Lexicon analysis to evaluate market penetration


One thing I noticed while reviewing some Russian texts is that not all bloggers use the same terms; and at the same time, words that English speakers use may not necessarily translate back and forth to other languages in terms of frequency.

Yet, I thought that this could be an approach to analyzing market penetration of XML. The problem current XML analysts have is that it's hard to analyze market penetration given that the sampling mechanisms are difficult where cell phones are sparse, but the connections to the web may not match that which is in more industrialized nations.

One approach to this problem is to look at word usage in Area 1; compare that with the word's frequency in Area 1. We'll have a baseline in Area 1 since we know the percent usage relative to market penetration in a more easily analyzed region.

Then take those results and take a similar word in Area 2, and look at the usage of that word in area 2. The problem in area 2 is that we don't know the penetration rate, but we can compare the word frequency ratios to find the unknown.

This would allows us to identify the scope of untapped market penetration, and create both content and tools that are tailored to our target culture. This would allow a country or region outside an area to analyze their progress not based on the ability to sample, but on the ability to adjust market use of words.

To discuss further, use this tag:


XML Open Feed Registry

Showcasing feed content with new people


As feeds start flying back and forth, and users add content to the feed, not their blogs, there could be some interest in developing tools which intersect these open feeds, and analyze the content.

This tool would convert open feed flow after it is published in XML, convert the analysts into a searchable XML-feed that either the universal search tools or aggregators could incorporate, analyze, breakdown, and display.

To discuss further, use this tag:


XML NewsLetter

Publisher opens content to search-feed access


If you think about Africa, they jumped in their telecommunications efforts by simply introducing cell phones. They didn't have to lay down massive numbers of land lines.

Think of the same analogy for bloggers who publish newsletters. They have the ability to use XML feeds, but still rely on e-mail newsletters.

The leap would allow them to quickly translate their newsletters into XML feeds by opening up their communication channels to external newsletter readers that translate the content-flows into a feed that others can incorporate.

This means readers do not have to rely on the e-mail-newsletter-convert-to-feed tool, and simply grab open content and convert it to feeds.

This tool would hunt down blogs and websites that use newsletters, report these newsletters to a central platform, and then external readers could search through the newsletters to convert them into feeds that could be cross analyzed, organized, and aggregated.

The quick way would be simply to have a universal newsletter hunter that could convert any newsletter into content. But why stop there, simply allow any content to get translate into a feed with a one stop button.

This open feed registry would also have a mapping tool of open feeds. It would identify patterns and identify groups.

Users would be able to search the feeds of others as content moves from publisher to subscriber. This would allow users to subscribe to e-mail newsletters without using the e-mail to XML conversion tool.

This tool would capture newsletter requests, post it to XML and extract data for other indexing, searches, and posting in aggregators.

To discuss further, use this tag:


XML Feed Analysis Tools

Analyzing multi-feed search results


Feed analysis tools are need to take multi-feed-results and analyze the outs. This tool would compare the feed outputs, explore the reported links, create tags fro new content, conduct tag analysis, and do specific search commands unique to feeds in terms of order, arrays and provide multi-result outputs.

To discuss further, use this tag:


XML Duplicate Analysis

Identifies variations of the same content


Have you ever read a speech or quote that multiple bloggers have linked to, yet each blogger finds something different to point out?

It would be nice if the single speech or quote was a stand-alone item, and a tool would take all the comments, links, and commentary about that original source, and consolidate these secondary comments into a single page.

This tool would take a specific quote, speech, or original content, then map the external links, tags, and commentary to that document.

The idea would be that instead of reading through the same quotes with variations, it would be nice to have the same text and content, but different links from different users aggregated or injected into that original document.

Each tagger or blogger would have a unique identifier so that links could be distinguished. This tool would allow readers to combine all the links into a composite picture.

All the quotes from all sources would be injected, then tools could be applied to that quote to analyze the subsequent use of those links in a visual arrays.

To discuss further, use this tag:


XML Search Order

Order-specific searches


Have you ever entered a search term into google, but were looking for a specific page? Perhaps you are trying to find a specific quote. You use quotation marks around the content and you find it.

OK. Now, think about a string of words like cat-dog-mouse. What if you want to find a page that has those three words or tags in that order, but you do not want anything that has the words in this order dog-cat-mouse. How do you do it?

There needs to be a system that allows users to apply these order-specific rules to tags when creating XML feed searches. There will be time when tags are given priority in the blogs, and a tag like dog will have greater importance than a tag like rock.

These ranking tools have yet to be applied to tagging. But there needs to be some thought put into creating search tools for feeds that can differentiate between different tags, and distinguish both the order of the tags and the relative importance of a tag in the search result.

As it stands, if we are doing a search for a certain tag, they're all given equal weight. But there will be a time when we'll be using tags to expedite searches, but we'll want to give more weight to one tag than another.

What's needed is something that will differentiate between these tags, and report different results based on the order the tag is searched or requested. That is, we should be able to search for multiple tags, not just one at a time.

To discuss further, use this tag:


XML Convert URL

Converts any url to xml


Ever come across a document or a site that you want in a feed? If you can figure it out, there are ways to do it. This is fine with URLs.

But think about content. It would be nice if there were ways to simply focus on the URL and convert that URL into a feed, then have an end-tool that would seamlessly convert that reported content into a final format or protocol that I want.

This is to say that if I have a .pdf file, it would be nice to be able to convert the content into a feed, then have my aggregate reproduce that content in either a pdf content with the images arranged in my template, or in a new format that is consistent with my preferred template. Keeping in mind the original copyright restrictions, of course.

This tool would convert any standard into XML, then post it in the aggregator to convert it back or into a third format. Take an image, search result, shortened url, pdf, document, or text file and report it as XML, then convert it to a third format that I, as the end-reader prefer.

To discuss further, use this tag:


XML Link Rot Registry

Sharing replacement urls


As tags take off, the content may get wiped out. The trick will be to still use the same content, but then still link back to the original content despite it being no longer available.

This tool would integrate with search engine cache systems and arching to post content into a registry. When a link or tag was requested from a feed that has outdated links, this tool would seamlessly provide a replacement uri for that content.

It would automatically transfer-translate a rotten url into something that the feed reader could work with and post, and provide a seamless alternative to archived data in either the wayback machine or search engine archive.

Once the data was requested and the replacement content identified, this new URL would be posted and published in a central XML data format that other feed readers would know to look for in cases where the feed url was rotten.

The idea is that even if someone 20 years from now signs up for a feed created today, the cache system would have the urls already archived and the original feed would seamlessly link to the archived data, without any need to change URLs or create better links to the tags.

To discuss further, use this tag:


XML Search Text

Auto-feeds for highlighted text


Ever found a phrase you want to look into more? Take a quote, you throw it into google and look for other people who have used the quote. Now, you can do the same thing with tags.

But wouldn't it be nice if you could simply highlight the quote and auto-generate a tag that is instantly registered and you could use to auto-hunt all other content that may or may not use that tag.

This tool would allow users to quickly tag text or quotes, create a new tag, and find other content that may or may not be pinged XML content and then find out what they are saying.

Users would have the highlighted text as a tag. System would save the tag in the registry, then ensure that the tag was a valid tag-format [in terms of spaces, spelling, formatting]

To discuss further, use this tag:


XML Linked Text

Analyzing links in target text of feed


This tool would allow users to look at the text of a popular quote or phrase, then analyze those common links. Rather than individually look at each quote, the tool would aggregate all the links.

Users would be able to identify the common links, organize the linked content into user defined groups, identify trends or patterns in the linked text.

A single mouse-over on the feed results would report a powerpoint-like thumbnail image of that content. The text-results could be converted to thumbnails for new arrangement into templates.

The tool would auto generate the feed uri to add image-link-text when doing an image search. When doing a search, users would get the associated image and a quick box for the feed url to post to their aggregator.

To discuss further, use this tag:


XML URI Search

Reporting key phrases in uri list


Ever gone down a list of feed-uri, but been unable to search them? All the phrases run together. What would be nice if there was a way to find the word dog in the following string of letters: textdogcat.

A tool is needed that will parse the uri, find segments, and then report the results. This would allow end-users to review a list of bookmarks and feed uris not based on content, but on key order of characters.

Before it was the order of words, now it is the order of letters, but without the spaces. This approach would allow cross-feed searching. There is valuable information in the URI that could be aggregated for faster indexing.

To discuss further, use this tag:


XML Search Comparison

Multi-feed comparison


A tool is needed to allow users to compare quickly and transparently different feeds based on content.

Users would load up two to compare, kind of like how wayback allows you to compare two version of the same website. This tool would go between publishers, and compare the different outputs of their content.

The tool could identify similarities. Also the tool would combine both feeds into a single stream, giving one picture or feed without duplication.

The tool would be useful in analyzing feeds with similar tags, but different content. It would aggregate the similar feeds into a new feed based on similar tags.

To discuss further, use this tag:


XML Custom Format

Custom output reports


It used to be that we were concerned with just search results from the search engines. Now, that we're using tags, it would be nice to have a standard system of reporting them for bibliographies.

That's where this tool comes in. It takes an external display standard, applies it to new feeds, and then reports the results into a single report that quickly displays it for bibliographies.

It determines all the elements needed, creates a template, finds the elements, then displays the data in the standard format.

To discuss further, use this tag:


XML Image Convert

Converts image-of-text to text


Ever seen a picture of something in another language, but wished you could translate it?

One thing that is very frustrating about .pdf documents and scanners is that sometimes you really want the text searchable.

The problem is compounded when you have a photograph of text, or .jpg of something that is a text-based-tag, like a sign.

If you’re trying to find a picture of a sign that says [cat] so that you can go visit the stores across the street and set up a photo shoot, you have to hunt all over the place in a book, or have your own team make a new sign with those words.

But what if you have a way of searching for text in images. And what if you don’t have access to an OCR to convert something from an image of Chinese text then your native Russian language?

It would be nice to be able to take a picture of a sign in Chinese and have a tool that will say in Russian what it means: You can know whether the picture you are using in your feed is actually saying what you think it says.

Remember, people may not be able to read a sign, but they can audibly hear the words. If someone is blind is using the image-searchers, they cannot read the word CAT on the picture of the sign.

What’s needed is a way of converting copies of faxes that are saved as .jpg in to text. This is to say a way of converting a picture of a ward into something that a search engine can find.

Let’s apply this concept to tags and feeds. If I have a Flicker account, with a picture of a sign that says CAT in Chinese, I might want to know that in another language. But the person who saves the images or applies the tag may call it FELINE.

The trick for XML search tools will be to establish a system that can do what the spammers do: Convert text-images into text.

So, next time you find yourself railing against spammers, think about the tools they use to do their work. Then think about how their tools could be modified for good.

In this case, blind people could have an audible feed fed to them through a pod casting system that says exactly what is on the sign. They could rely on street signs to give them information because their XML related product can concert a sign that says CAT into an audible sound saying “CAT”.

Then, the next step is to then permit these image to tag conversion tools be integrated with language-conversion tools. Thus, a blind man from China could walk down the street in India and be able to understand the Hindi signs.

The next step is then to use this tool as a search platform for tags and feeds. This tool would crate a feed and permit searches, then convert the image in the text to xml, then a third format for final display.

So, the tool would take a picture of a document that has text; convert that text in the image to XML; then translate that XML into the desired format. This could be something like a .doc file, .jpg, .txt, or a new .jpg image using a different XML tag.

Then the next step is to combine the geolocation technology with that image, and permit users to search for an image of a sign that says CAT, then look for other images that are across the street.

The tool would be able to images based on location, object size, color, subject, time of day, and location. And the results would be reported as a feed that could be injected with other tags, or be analyzed and have bridge feeds created.

This is essentially the same as integrating tag and image search with image conversion tools from .jpg to .txt then XML and the final desired format

To discuss further, use this tag:


SB


XML Search Bridge

Identify common sites related to search results


Sometimes when we are comparing feeds, the relationship isn’t all that clear. We essentially have two feeds that do not appear to overlap or intersect.

However, there are commonalities. Think of a middle feed between these apparently unrelated feeds. Feed A on the left, and Feed B on the right. The middle feed is the Bridge.

When we do an –or- search in a feed search, we may get one, both, or neither as the result.

When we are doing feed-focused searches [not terms to create fees, but searching across feeds themselves] two different feeds may not share all the same terms, but report as there being nothing in common.

What is needed is a mechanism to recognize a percentage of the similarities between the two feeds, and recognize what elements are not common in the feed, but what elements on the middle feed link to both feeds, but not at the same time or with the same tag.

Feed A could be about a pre-event to events in Feed B. But a single search would not yield a common link between Feeds A and B.

This search function would create a third feed between two feeds that do not appear to have anything in common. This Bridge Feed would identify common content, links, tags, and XML data related to the search results.

Although Feed A does not share all the terms in the feed search, this Bridge Feed would display the tags that could be common to both feed had a Tag Thesaurus been used. Feed A and B may have no textual-similarities, but the underlying Tag-Concepts are the same, related, or sequential in order.

Thus, although two feeds may not be related or obviously containing the same language, a search tool that knew the difference between cat dog –vs- dog cat [in terms of order] would support this Bridge Feed.

The Bridge Feed may not have common terms for both feeds. But the Bridge Feed is something we create by saying, There is a thread of common concepts, links, data that each of these feeds points to, but neither universally contains all this data.

Thus, when we create a bridge feed, we can then apply that bridge feed to new data, to find new relationships between feeds where there does not appear to be anything related.


To discuss further, use this tag:


XML Search Array

Displays frequency of terms in searches


Have you ever entered a string of words into a search engine, thinking there is something there.

Perhaps you find a list of words or a cooking list. But you miss the recipe on the radio. But you do remember that the ingredients are butter, oregano, and chives.

You really want to make that dinner with the special ingredients. What to do? In the Google world you type in what you know and hope something hits.

However, what if you got one of the ingredients wrong; or the radio announcer was reading copy that hadn’t been fact checked? You might be out of luck.

Not anymore. There’s a way of searching that is called array searching. You simply type in your string of words, and you get a matrix. The engine will search each term against all others.

Think of a chess board. Horizontally and vertically you have rows and columns. Think of your words as going along each axis.

Along the top axis you have butter oregano and chives.

The same along the left axis, or up and down: butter oregano and chives.

We know that one of the ingredients is wrong, but we don’t know which one. So, the search array will compare all the words and report the results.

The results come back to you in the form of a bar chart. In each of the boxes that intersect the horizontal and vertical axis, there is a result.

In this case, we look at the results, and find that chives have a low number of hits, while butter and oregano are high.

That’s what makes this search tool different. It compares each search term to all the others, reports and array, and you visually see which search term is not like the others.

Now let’s apply this search concept to tags and feeds. Suppose we are looking for a tag, and we want to inject 200 tag search terms into the feed-search tool. Today, unless all 200 tags match something, you get nothing.

But using the array approach, you can get a visual map of which of those tags are comparing.

The higher the bar in each intersection, the greater the usage.

I’d rather see from a list of 200 words that I throw into a tool, which of them are getting used and not. This is useful when analyzing the success in getting concepts in the blogosphere adopted.

At the same time, if I want to create a novel term, if I throw in all my concepts and using a tag thesaurus, I can tweak my concept to be something that is ordered correctly, not necessarily used in the way I prefer not, and at the same time is specific to my product.

This tool essentially is a visual depiction of the most promising connections for search terms and tags. But the concept can also be applied to feeds.

Using our bridging concept, we can break down the various feeds into bridges, find new patterns, and develop a graph of the most to least used terms. The bar chart would show the largest to smallest number of intersections.

So, if I’m trying to create content that people will relate to, but not duplicate [create value], then this tool would show case whether what I’m discussing in my feed is novel enough for my subscribers. If my concept is already in use, I can save my time and refocus my efforts on something more productive.

Think of this as a tool that will help increase efficiency. If we know what everyone else is working on, we can ensure that our efforts are focused on what we can do best, or what we have that is unique.

At the same time, if there are high-hits in a target area that we are competing, we can more easily identify what strategies we need to use to better penetrate and compete.

This tool would graphically display the results for search terms, tags, and feed results with a java pop-up box. As we scroll over each intersection, we can get other data of interest related to other analysis and feeds we choose to inject into our aggregator.

To discuss further, use this tag:


XML Lead Tagger

Identifies portals with quality, and novel tags


Have you ever noticed that sometimes when you are looking for something, you can’t quite find it?

There are times when you may be looking for something, and you know it relates to an original link or document. All you have is the link, but you have no idea which content or site you need to look at.

But what if you knew that there were 3 links on that target site? Right now, you’re out of luck. You can only search for one link-to-this-site at a time.

Sure, you can do some really funky coding stuff in Google and find it, but the problem you also have is that you only have a partial link for the other two.

What users need is a way of doing an array search on links. Again, we have partial links that get added into an array, and then an output that shows the WebPages with those intersections.

Got that?

Let’s apply the above problem to the world of tags and feeds. Again, we hope to find new content, and we have only partial tags to work with. This tool will take those partial tags and feed information, and show us all the pages, bogs, and content that are using or link to those tags and feeds.

The tool will identify [from a list of target tags, feed bridges, and other parameters] which of the blogs have the target information.

This type of tool would be useful for tagging because we could identify who is consistently covering items of interest, not just in terms of number of blog or feeds provided, but who is consistently providing tagged information that relates to our area of interest

Again, the goal is not to find tags, but to find quality sources of information that we can spend more time on.

Think of this as a root search where we identify portals with a large number of tags, and then use the tagging information [or partial information] to backtrack into who is using those tags, and how they relate to other content or feeds provided.

To discuss further, use this tag:

Other tags

Quick tip: Newsgator Online has a tool in java converting "mail to xml": Newsgator Manager: Add a Feed: Smart Feeds : E-mail feeds



XML Tag Monitoring Tool

Monitors tag uses, last look, updates


Tags are taking off. With time, many people will have many tags that they are monitoring, actively using, and dialoging with. Tags may also go in new directions.

Let's consider, as an analogy, how links took off. With time, there were tools in the browsers called bookmarks that allowed users to organized these links. Then came webpages bookmarks that you could save, download, share, and organize into groups. These transformed into XML related products like del.icio.us and furl.

I see the same thing happening with tags that happened with links. Namely, tags are going to get saturated and, like feed content and feeds, will not only take on a life of their own, but become an obstacle to clear analysis.

This isn't to say that tags are bad. Rather, the way forward is to consider tools that will help end-users manage specifically their tags.

At this juncture, it is clear that end-users can individually track their tags using various feed monitoring tools. However, these tend to be a bit cumbersome as each tag has to be loaded as a specific feed, then individually tracked.

Also these feed-based tag-tracking systems are not really all that conducive to updates in that its hard to see what new tags have been added by simply relying on a single feed.

It is possible with NewsGator to find new content, but we're still talking about feeds that users have to individually click on to find new content. At worst, all the tags get segregated into separate feeds that the users can individually monitor in their aggregator, then pull them all together.

What I propose is way of approaching tags the same way that people have approached links: Namely, develop tools that help to specifically organize tags, and then integrate these organizationally systems into the existing XML products and platforms like blogs, aggregators, and integrate with the existing search tools like Technorati and other XML feed searchers.

To discuss further, use this tag:


LEGAL NOTICE


Creative Commons License

This work is licensed under a Creative Commons License.

You may not copy any of this work to promote a commercial product on any site or medium in the universe.

If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

Free to use for non-commercial uses. Link to this original blogspot and cite as .



Tests


I would encourage users to look at the various existing platforms and search mechanisms and see whether the current search tools could be enhanced if they had link-uri-related features also applied to feeds and tags.

Specifically, if we look at Technorati, we can see that each watch list allows users to individually track a specific search. Also, something like MyStack can aggregate these searches into a single output. More broadly, the aggregators can translate these individual searches into a consolidated approach.

In the short term, rather than re-invent a new architecture or protocol designed to specifically organize tags then integrate them into the existing platforms, users might want to see if they have occasion to change the Technorati watch-list code, tailor it to a specific new tag, then add that URI to an aggregator to see if the results display.

Also, users may wish to take the existing 2XML conversion tools [convert HTML, searches, other tasks into XML-feeds, like 2RSS] and see whether these tools can work on various searches.

For example, if you have a link from a search engine that doesn't give you an XML feed, see if there is a way to convert the search-URL from the URL-format into something that your aggregator can read, use, and display.

For example, take a URL for a .txt document, see if you can use a system to convert that .txt document URL into something that is XML-readable, then get it to display in your aggregator, then have your aggregator convert it into a new format that you choose.

Also, see if you can find new strings of terms, enter them as a tag, is see if you can find content already published that doesn't specifically have a tag, but still reports in the tag list.


Going forward


As you can see, the above challenges are not necessarily clear. Thus, I propose the following solutions to modernize the XML products into something that is likely to embrace tags just the way that bookmarks embraced links.

The idea is to make tags just as easy to find, archive, index, and incorporate into feeds as we do with webpages and links into current XML products.

Ready?


XML Tag Registry

Report and recording tags


This system can identify strings of words, translate them into tags, and then register these search groups as new tags that others can then commonly-discuss.

The idea is that content that is already published can be injected with a new tag, and others can quickly find this tag in old content.

This system would store and record tags in URL format. This would be a way to show what's changed and added since the last visit to the tag-list. Users would have the option to check all-as-read.

To discuss further, use this tag:


XML Tag Mapping

Mapping tool for tags


As it stands, there are visual mapping tools for del.icio.us tags, Flickr images. You can visually see where the items relate to each other in a visual hierarchy or maps. Kind of like the Six Degrees of Kevin Bacon game.

What's needed is something that focuses exclusively on the tags themselves, regardless whether they are words or images.

These tag mapping tools would follow the discussion for either one platform or many platforms and aggregate all the tag-discussions into a visual map. This would allow the end-user to see which nodes have taken off in terms of time.

Flickr allows users to take an image and map them in terms of both usage and where the image was taken on the blog. Del.icio.us has a link map.

The next step is to apply the wiki-concept that IBM uses which visually shows changes in a wiki, and then apply that concept to tagging.

To discuss further, use this tag:


XML Universal Search

Search all platforms with a single feed


Right now, users can go to a single platform like Mama search and search many search engines. However, there's no single system for all XML and non-XML systems.

What's needed is a platform that can search everything. Not just like MyStack which focuses on feeds that have been pinged, but everything: News, photos, blogs, search engines, websites. The system needs to look for both XML and non-XML content that may or may not be pinged into FeedMesh.

The idea is that a single feed could cross all search platforms and uses would get a single XML feed for that single, specific search that looks both forward and backward in time. This system would integrate with the existing search engines.

One search would return results which can get broken down into categories. Users can either define prior to the search-execution which categories they want displayed; or they can take the composite list, and have their aggregator assign the content into folders. In short, the foldering can be either applied at the front even of the search or at the back end as the results report in the feeds.

To discuss further, use this tag:


XML Awareness Analysis

Lexicon analysis to evaluate market penetration


One thing I noticed while reviewing some Russian texts is that not all bloggers use the same terms; and at the same time, words that English speakers use may not necessarily translate back and forth to other languages in terms of frequency.

Yet, I thought that this could be an approach to analyzing market penetration of XML. The problem current XML analysts have is that it's hard to analyze market penetration given that the sampling mechanisms are difficult where cell phones are sparse, but the connections to the web may not match that which is in more industrialized nations.

One approach to this problem is to look at word usage in Area 1; compare that with the word's frequency in Area 1. We'll have a baseline in Area 1 since we know the percent usage relative to market penetration in a more easily analyzed region.

Then take those results and take a similar word in Area 2, and look at the usage of that word in area 2. The problem in area 2 is that we don't know the penetration rate, but we can compare the word frequency ratios to find the unknown.

This would allows us to identify the scope of untapped market penetration, and create both content and tools that are tailored to our target culture. This would allow a country or region outside an area to analyze their progress not based on the ability to sample, but on the ability to adjust market use of words.

To discuss further, use this tag:


XML Open Feed Registry

Showcasing feed content with new people


As feeds start flying back and forth, and users add content to the feed, not their blogs, there could be some interest in developing tools which intersect these open feeds, and analyze the content.

This tool would convert open feed flow after it is published in XML, convert the analysts into a searchable XML-feed that either the universal search tools or aggregators could incorporate, analyze, breakdown, and display.

To discuss further, use this tag:


XML NewsLetter

Publisher opens content to search-feed access


If you think about Africa, they jumped in their telecommunications efforts by simply introducing cell phones. They didn't have to lay down massive numbers of land lines.

Think of the same analogy for bloggers who publish newsletters. They have the ability to use XML feeds, but still rely on e-mail newsletters.

The leap would allow them to quickly translate their newsletters into XML feeds by opening up their communication channels to external newsletter readers that translate the content-flows into a feed that others can incorporate.

This means readers do not have to rely on the e-mail-newsletter-convert-to-feed tool, and simply grab open content and convert it to feeds.

This tool would hunt down blogs and websites that use newsletters, report these newsletters to a central platform, and then external readers could search through the newsletters to convert them into feeds that could be cross analyzed, organized, and aggregated.

The quick way would be simply to have a universal newsletter hunter that could convert any newsletter into content. But why stop there, simply allow any content to get translate into a feed with a one stop button.

This open feed registry would also have a mapping tool of open feeds. It would identify patterns and identify groups.

Users would be able to search the feeds of others as content moves from publisher to subscriber. This would allow users to subscribe to e-mail newsletters without using the e-mail to XML conversion tool.

This tool would capture newsletter requests, post it to XML and extract data for other indexing, searches, and posting in aggregators.

To discuss further, use this tag:


XML Feed Analysis Tools

Analyzing multi-feed search results


Feed analysis tools are need to take multi-feed-results and analyze the outs. This tool would compare the feed outputs, explore the reported links, create tags fro new content, conduct tag analysis, and do specific search commands unique to feeds in terms of order, arrays and provide multi-result outputs.

To discuss further, use this tag:


XML Duplicate Analysis

Identifies variations of the same content


Have you ever read a speech or quote that multiple bloggers have linked to, yet each blogger finds something different to point out?

It would be nice if the single speech or quote was a stand-alone item, and a tool would take all the comments, links, and commentary about that original source, and consolidate these secondary comments into a single page.

This tool would take a specific quote, speech, or original content, then map the external links, tags, and commentary to that document.

The idea would be that instead of reading through the same quotes with variations, it would be nice to have the same text and content, but different links from different users aggregated or injected into that original document.

Each tagger or blogger would have a unique identifier so that links could be distinguished. This tool would allow readers to combine all the links into a composite picture.

All the quotes from all sources would be injected, then tools could be applied to that quote to analyze the subsequent use of those links in a visual arrays.

To discuss further, use this tag:


XML Search Order

Order-specific searches


Have you ever entered a search term into google, but were looking for a specific page? Perhaps you are trying to find a specific quote. You use quotation marks around the content and you find it.

OK. Now, think about a string of words like cat-dog-mouse. What if you want to find a page that has those three words or tags in that order, but you do not want anything that has the words in this order dog-cat-mouse. How do you do it?

There needs to be a system that allows users to apply these order-specific rules to tags when creating XML feed searches. There will be time when tags are given priority in the blogs, and a tag like dog will have greater importance than a tag like rock.

These ranking tools have yet to be applied to tagging. But there needs to be some thought put into creating search tools for feeds that can differentiate between different tags, and distinguish both the order of the tags and the relative importance of a tag in the search result.

As it stands, if we are doing a search for a certain tag, they're all given equal weight. But there will be a time when we'll be using tags to expedite searches, but we'll want to give more weight to one tag than another.

What's needed is something that will differentiate between these tags, and report different results based on the order the tag is searched or requested. That is, we should be able to search for multiple tags, not just one at a time.

To discuss further, use this tag:


XML Convert URL

Converts any url to xml


Ever come across a document or a site that you want in a feed? If you can figure it out, there are ways to do it. This is fine with URLs.

But think about content. It would be nice if there were ways to simply focus on the URL and convert that URL into a feed, then have an end-tool that would seamlessly convert that reported content into a final format or protocol that I want.

This is to say that if I have a .pdf file, it would be nice to be able to convert the content into a feed, then have my aggregate reproduce that content in either a pdf content with the images arranged in my template, or in a new format that is consistent with my preferred template. Keeping in mind the original copyright restrictions, of course.

This tool would convert any standard into XML, then post it in the aggregator to convert it back or into a third format. Take an image, search result, shortened url, pdf, document, or text file and report it as XML, then convert it to a third format that I, as the end-reader prefer.

To discuss further, use this tag:


XML Link Rot Registry

Sharing replacement urls


As tags take off, the content may get wiped out. The trick will be to still use the same content, but then still link back to the original content despite it being no longer available.

This tool would integrate with search engine cache systems and arching to post content into a registry. When a link or tag was requested from a feed that has outdated links, this tool would seamlessly provide a replacement uri for that content.

It would automatically transfer-translate a rotten url into something that the feed reader could work with and post, and provide a seamless alternative to archived data in either the wayback machine or search engine archive.

Once the data was requested and the replacement content identified, this new URL would be posted and published in a central XML data format that other feed readers would know to look for in cases where the feed url was rotten.

The idea is that even if someone 20 years from now signs up for a feed created today, the cache system would have the urls already archived and the original feed would seamlessly link to the archived data, without any need to change URLs or create better links to the tags.

To discuss further, use this tag:


XML Search Text

Auto-feeds for highlighted text


Ever found a phrase you want to look into more? Take a quote, you throw it into google and look for other people who have used the quote. Now, you can do the same thing with tags.

But wouldn't it be nice if you could simply highlight the quote and auto-generate a tag that is instantly registered and you could use to auto-hunt all other content that may or may not use that tag.

This tool would allow users to quickly tag text or quotes, create a new tag, and find other content that may or may not be pinged XML content and then find out what they are saying.

Users would have the highlighted text as a tag. System would save the tag in the registry, then ensure that the tag was a valid tag-format [in terms of spaces, spelling, formatting]

To discuss further, use this tag:


XML Linked Text

Analyzing links in target text of feed


This tool would allow users to look at the text of a popular quote or phrase, then analyze those common links. Rather than individually look at each quote, the tool would aggregate all the links.

Users would be able to identify the common links, organize the linked content into user defined groups, identify trends or patterns in the linked text.

A single mouse-over on the feed results would report a powerpoint-like thumbnail image of that content. The text-results could be converted to thumbnails for new arrangement into templates.

The tool would auto generate the feed uri to add image-link-text when doing an image search. When doing a search, users would get the associated image and a quick box for the feed url to post to their aggregator.

To discuss further, use this tag:


XML URI Search

Reporting key phrases in uri list


Ever gone down a list of feed-uri, but been unable to search them? All the phrases run together. What would be nice if there was a way to find the word dog in the following string of letters: textdogcat.

A tool is needed that will parse the uri, find segments, and then report the results. This would allow end-users to review a list of bookmarks and feed uris not based on content, but on key order of characters.

Before it was the order of words, now it is the order of letters, but without the spaces. This approach would allow cross-feed searching. There is valuable information in the URI that could be aggregated for faster indexing.

To discuss further, use this tag:


XML Search Comparison

Multi-feed comparison


A tool is needed to allow users to compare quickly and transparently different feeds based on content.

Users would load up two to compare, kind of like how wayback allows you to compare two version of the same website. This tool would go between publishers, and compare the different outputs of their content.

The tool could identify similarities. Also the tool would combine both feeds into a single stream, giving one picture or feed without duplication.

The tool would be useful in analyzing feeds with similar tags, but different content. It would aggregate the similar feeds into a new feed based on similar tags.

To discuss further, use this tag:


XML Custom Format

Custom output reports


It used to be that we were concerned with just search results from the search engines. Now, that we're using tags, it would be nice to have a standard system of reporting them for bibliographies.

That's where this tool comes in. It takes an external display standard, applies it to new feeds, and then reports the results into a single report that quickly displays it for bibliographies.

It determines all the elements needed, creates a template, finds the elements, then displays the data in the standard format.

To discuss further, use this tag:


XML Image Convert

Converts image-of-text to text


Ever seen a picture of something in another language, but wished you could translate it?

One thing that is very frustrating about .pdf documents and scanners is that sometimes you really want the text searchable.

The problem is compounded when you have a photograph of text, or .jpg of something that is a text-based-tag, like a sign.

If you’re trying to find a picture of a sign that says [cat] so that you can go visit the stores across the street and set up a photo shoot, you have to hunt all over the place in a book, or have your own team make a new sign with those words.

But what if you have a way of searching for text in images. And what if you don’t have access to an OCR to convert something from an image of Chinese text then your native Russian language?

It would be nice to be able to take a picture of a sign in Chinese and have a tool that will say in Russian what it means: You can know whether the picture you are using in your feed is actually saying what you think it says.

Remember, people may not be able to read a sign, but they can audibly hear the words. If someone is blind is using the image-searchers, they cannot read the word CAT on the picture of the sign.

What’s needed is a way of converting copies of faxes that are saved as .jpg in to text. This is to say a way of converting a picture of a ward into something that a search engine can find.

Let’s apply this concept to tags and feeds. If I have a Flicker account, with a picture of a sign that says CAT in Chinese, I might want to know that in another language. But the person who saves the images or applies the tag may call it FELINE.

The trick for XML search tools will be to establish a system that can do what the spammers do: Convert text-images into text.

So, next time you find yourself railing against spammers, think about the tools they use to do their work. Then think about how their tools could be modified for good.

In this case, blind people could have an audible feed fed to them through a pod casting system that says exactly what is on the sign. They could rely on street signs to give them information because their XML related product can concert a sign that says CAT into an audible sound saying “CAT”.

Then, the next step is to then permit these image to tag conversion tools be integrated with language-conversion tools. Thus, a blind man from China could walk down the street in India and be able to understand the Hindi signs.

The next step is then to use this tool as a search platform for tags and feeds. This tool would crate a feed and permit searches, then convert the image in the text to xml, then a third format for final display.

So, the tool would take a picture of a document that has text; convert that text in the image to XML; then translate that XML into the desired format. This could be something like a .doc file, .jpg, .txt, or a new .jpg image using a different XML tag.

Then the next step is to combine the geolocation technology with that image, and permit users to search for an image of a sign that says CAT, then look for other images that are across the street.

The tool would be able to images based on location, object size, color, subject, time of day, and location. And the results would be reported as a feed that could be injected with other tags, or be analyzed and have bridge feeds created.

This is essentially the same as integrating tag and image search with image conversion tools from .jpg to .txt then XML and the final desired format

To discuss further, use this tag:


SB


XML Search Bridge

Identify common sites related to search results


Sometimes when we are comparing feeds, the relationship isn’t all that clear. We essentially have two feeds that do not appear to overlap or intersect.

However, there are commonalities. Think of a middle feed between these apparently unrelated feeds. Feed A on the left, and Feed B on the right. The middle feed is the Bridge.

When we do an –or- search in a feed search, we may get one, both, or neither as the result.

When we are doing feed-focused searches [not terms to create fees, but searching across feeds themselves] two different feeds may not share all the same terms, but report as there being nothing in common.

What is needed is a mechanism to recognize a percentage of the similarities between the two feeds, and recognize what elements are not common in the feed, but what elements on the middle feed link to both feeds, but not at the same time or with the same tag.

Feed A could be about a pre-event to events in Feed B. But a single search would not yield a common link between Feeds A and B.

This search function would create a third feed between two feeds that do not appear to have anything in common. This Bridge Feed would identify common content, links, tags, and XML data related to the search results.

Although Feed A does not share all the terms in the feed search, this Bridge Feed would display the tags that could be common to both feed had a Tag Thesaurus been used. Feed A and B may have no textual-similarities, but the underlying Tag-Concepts are the same, related, or sequential in order.

Thus, although two feeds may not be related or obviously containing the same language, a search tool that knew the difference between cat dog –vs- dog cat [in terms of order] would support this Bridge Feed.

The Bridge Feed may not have common terms for both feeds. But the Bridge Feed is something we create by saying, There is a thread of common concepts, links, data that each of these feeds points to, but neither universally contains all this data.

Thus, when we create a bridge feed, we can then apply that bridge feed to new data, to find new relationships between feeds where there does not appear to be anything related.


To discuss further, use this tag:


XML Search Array

Displays frequency of terms in searches


Have you ever entered a string of words into a search engine, thinking there is something there.

Perhaps you find a list of words or a cooking list. But you miss the recipe on the radio. But you do remember that the ingredients are butter, oregano, and chives.

You really want to make that dinner with the special ingredients. What to do? In the Google world you type in what you know and hope something hits.

However, what if you got one of the ingredients wrong; or the radio announcer was reading copy that hadn’t been fact checked? You might be out of luck.

Not anymore. There’s a way of searching that is called array searching. You simply type in your string of words, and you get a matrix. The engine will search each term against all others.

Think of a chess board. Horizontally and vertically you have rows and columns. Think of your words as going along each axis.

Along the top axis you have butter oregano and chives.

The same along the left axis, or up and down: butter oregano and chives.

We know that one of the ingredients is wrong, but we don’t know which one. So, the search array will compare all the words and report the results.

The results come back to you in the form of a bar chart. In each of the boxes that intersect the horizontal and vertical axis, there is a result.

In this case, we look at the results, and find that chives have a low number of hits, while butter and oregano are high.

That’s what makes this search tool different. It compares each search term to all the others, reports and array, and you visually see which search term is not like the others.

Now let’s apply this search concept to tags and feeds. Suppose we are looking for a tag, and we want to inject 200 tag search terms into the feed-search tool. Today, unless all 200 tags match something, you get nothing.

But using the array approach, you can get a visual map of which of those tags are comparing.

The higher the bar in each intersection, the greater the usage.

I’d rather see from a list of 200 words that I throw into a tool, which of them are getting used and not. This is useful when analyzing the success in getting concepts in the blogosphere adopted.

At the same time, if I want to create a novel term, if I throw in all my concepts and using a tag thesaurus, I can tweak my concept to be something that is ordered correctly, not necessarily used in the way I prefer not, and at the same time is specific to my product.

This tool essentially is a visual depiction of the most promising connections for search terms and tags. But the concept can also be applied to feeds.

Using our bridging concept, we can break down the various feeds into bridges, find new patterns, and develop a graph of the most to least used terms. The bar chart would show the largest to smallest number of intersections.

So, if I’m trying to create content that people will relate to, but not duplicate [create value], then this tool would show case whether what I’m discussing in my feed is novel enough for my subscribers. If my concept is already in use, I can save my time and refocus my efforts on something more productive.

Think of this as a tool that will help increase efficiency. If we know what everyone else is working on, we can ensure that our efforts are focused on what we can do best, or what we have that is unique.

At the same time, if there are high-hits in a target area that we are competing, we can more easily identify what strategies we need to use to better penetrate and compete.

This tool would graphically display the results for search terms, tags, and feed results with a java pop-up box. As we scroll over each intersection, we can get other data of interest related to other analysis and feeds we choose to inject into our aggregator.

To discuss further, use this tag:


XML Lead Tagger

Identifies portals with quality, and novel tags


Have you ever noticed that sometimes when you are looking for something, you can’t quite find it?

There are times when you may be looking for something, and you know it relates to an original link or document. All you have is the link, but you have no idea which content or site you need to look at.

But what if you knew that there were 3 links on that target site? Right now, you’re out of luck. You can only search for one link-to-this-site at a time.

Sure, you can do some really funky coding stuff in Google and find it, but the problem you also have is that you only have a partial link for the other two.

What users need is a way of doing an array search on links. Again, we have partial links that get added into an array, and then an output that shows the WebPages with those intersections.

Got that?

Let’s apply the above problem to the world of tags and feeds. Again, we hope to find new content, and we have only partial tags to work with. This tool will take those partial tags and feed information, and show us all the pages, bogs, and content that are using or link to those tags and feeds.

The tool will identify [from a list of target tags, feed bridges, and other parameters] which of the blogs have the target information.

This type of tool would be useful for tagging because we could identify who is consistently covering items of interest, not just in terms of number of blog or feeds provided, but who is consistently providing tagged information that relates to our area of interest

Again, the goal is not to find tags, but to find quality sources of information that we can spend more time on.

Think of this as a root search where we identify portals with a large number of tags, and then use the tagging information [or partial information] to backtrack into who is using those tags, and how they relate to other content or feeds provided.

To discuss further, use this tag:

Other tags

" />