15 March 2005

XML Concepts: Two-way search engine integrating searchers with aggregators, tags, and content providers

Ever had someone ask you a question, but you didn’t immediately know the answer? As they walk out the door, you find the information.

Poof! They’re gone.

Want a way to get in touch with them? Every time someone searches for content and they hit your site or feed, that’s a potential subscriber.

But what if you have what they’re looking for, but they are not using the same terms you are? It would be nice if there was a follow-up system to give them the information. They might come back.

Enterprise brainstorming

  • How can content providers engage with not only subscribers and readers, but also those who are searching?

  • How does one create a system where their searches are publicly known to content providers, but their privacy is maintained?

  • How to track the searchers when they come to your site and then have a means to get back with them with content updates after they have left but still protect their privacy?

  • How can information-requests be aggregated so that content-providers can provide targeted responses to those who actually would benefit from the information?

  • How can users create signaling mechanisms that they would like follow-up information on possible future content, without giving away too much information that content providers can harass them?



  • 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 .


    XML Two-way Search

    Publishers giving content later

    Some call it time shifting. Others call it repurposing.

    Another way to look at is: Now that you know what they’re looking for, you can direct them to the more suitable information.

    What could be done is the searcher could permit later contact with the sites she visits. This means providing codes and protocols so that the search platform, content providers, and feed readers exchange information on an ongoing basis.

    Clearly, the protocols would relate to protecting the search, ensuring that the search results and secure, and the search requests are protected and secure.

    Two way search requirements

    A two-way search is something that would given content providers a means to provide information to the searcher. This is a retroactive look, not at content, but at searches.

    The trick to make this work is to have a mechanism that allows publishers to provide content and information back to the reader long after they have left, but still in a timely manner that is useful.

    Unlike the traditional web-searches available today, searchers could signal whether they wanted to have a follow-up-content [not necessarily contact] from the content providers.

    A successful follow-up tool would link content providers only with those who still want the information.

    It would be nice if there was a signaling system that the original information request was fulfilled; there’s no sense duplicating the work of many content providers.

    Once the searcher has indicate the search is over, they could close out the search and the content providers would know that no follow-up is either desired or useful.

    In fact, it would be interesting if the system could also provide other content providers feedback on what content was available or provided that did answer the question. Content providers could either choose to present this information more clearly, or provide signals on more useful sources.

    This tool would connect users-searchers to content; then provide a means for the content-providers to provide targeted updates to the searchers.

    The tool would protect the privacy of the searcher.

    XML Two way searches

    Linking content providers with searchers


    This is unlike PubSub in that it is not intended to continue a search; but do the opposite: Create a means by which content providers can timely provide valuable content to specific audiences that have already requested the information.

    Unlike a pull-based PubSub system, this system would be geared toward content providers who want to push content to those who have already indicated they are interested in certain information.

    Wouldn’t it be neat if the PubSub-like feed codes were available for content-providers? Imagine the bots that could go through that information, solving people’s problems and giving them the tools to achieve their goals. Content providers could have a field day giving people the information they actually need.

    Enabling technology


    Perhaps there could be tools that would permit the content provider and searcher to get into an immediate IM-conference once the searcher has left the site.

    Current IM’s permit this, and there is a platform called BlogChat, but those systems are not focused on searches per se, merely in creating a link between one user and another.

    Enterprise Goals


  • Improves content and information quality provided to customer

  • Convert searchers into readers and subscribers


  • To make this system work, we’ll have to look clearly at what we want the system to do.

    System Goals


  • 1.0 Support current searches

    1.1 Reliably report content for existing information

  • 2.0 Assist searchers with alternatives

    2.1. Makes suggestions on what content might be more useful

    2.2 Lets users know that the content provider can be contacted to provide additional information

  • 3.0 Signaling system to content provider

    3.1 Timely notification from the search platform that the information request continues

    3.2 Identifies the nature of the request

    3.3 Gives a realistic deadline when the content updates would be most useful

    3.4 Provides an estimated time when the search request will most likely be completed and further content updates would not be useful to a particular reader-searcher

  • 4.0 Match content update, search, and requester

    4.1 Method to archive searches

    4.2 Method to associate old searches with new content updates

    4.3 Reliably ensure that [a] the information-content updates are correctly connected to both [b] the correct search request; and [c] the individual requesting the information.

  • 5.0 Maintain privacy

    5.1 Have a secure system permitting readers to get linked with future content updates and changes

  • 6.0 Connection between content provider and searcher

    6.1 Call-back system to link the searcher with the content provider

  • 7.0 Cease work

    7.1 Method to quickly cancel all search requests and block efforts to provide content updates after the search has been completed


  • XML Two Way Tools

    Thoughts on implementation


    The integrated package, platform, and enterprise system would perform a number of functions [supporting goals above].

    Enabling Tools


  • Tool I. Detect searches and site hits [goal 4.0]

  • Tool II. Identify information helpful to the searcher [goal 4.3, 6.0]

  • Tool III. Stores search commands [goals 3.0, 4.0]

  • Tool IV. Identifies news content [goals 2.0, 3.0. 4.0, 6.0]

  • Tool V. Repings or auto-notifies the searcher that [a] new content exists; and [b] a specific content provider has potentially useful information [goals 4.0 5.0, 6.0]

  • Tool VI. Tool would learn from searches what types of search-responses are most likely to address, resolve and help with original search [Goals 1.0 and 2.0]

  • Tool VII. Users would have the option to continue searching [goal 4.3]; set a time limit [goal 7.0]; or decline information and updates for notification [goals 5.0, 7.0].

  • VIII. Platform would anonymously link searcher with search results [goal 5.0]



  • Technical challenges

    Such a system may not necessarily be best supported with XML. There could be a competing or unfolding protocol, standard, platform, or coding capability that could more easily perform this function than XML.

    It remains to be understood whether this type of platform could be best integrated within a more robust server, rather than placing the full burden of the system on XML.

    However, what we do know is that ultimately this type of search system will eventually have to integrate with feeds and the existing XML-related platforms.

    Coding Modules

    This portion of the discussion focuses on the specific tasks that the XML modules might perform to accomplish the two way search.


    Module 1: Detection System

    This would catalog the incoming searching, integrating with Tool I.

    Module 2: Analysis Tool

    This module would look at what information is unrelated to the search, and identify what information was rejected. This would help tailor the subsequent updates from the content provider.

    This module would look at similar searches of [a] the searcher [if available]; and [b] other searches on that content.

    The goal of this module would be to clearly identify the information which the searcher is not getting and content providers may wish to update.

    Module 3: Anonymously link searcher with search

    This module would focus on assigning codes to [a] the user-searcher; [b] the search request.

    This module would create a split code. One half of the code would be assigned to the searcher; and the other half to the search.

    Only the searcher would have access to the searcher’s half of the code. The content-provider would have no way of getting access to the searcher’s half of the code.

    User would have the option to delete the code to terminate the search. Code deletion would signal the platform and content provider that the content update is not intended for a specific user-reader-searcher.

    Other searchers with the same search-request would also be assigned the a similar matching code, but these matching codes would discriminate each content-reader from each other, in a way that no outside person could follow.

    If one searcher cancelled their half of the code, all other searchers with the same search-code would still have a valid search-code-request available for future matching.

    Other searchers would not be able to get access to the identifying search code for an individual searcher.

    Module 4: Generate/Notify

    This module issues commands to ping the searcher, this may be of interest. This module will only fill in ½ of the code.

    This module is the one that works with the aggregators to channel the information to the searchers.

    Module 5: Search Code Generator/Archive

    This module stores information about the search. It gives the searcher a tool to later trade to updated content.

    This is the key interface mechanism between [a] searcher; [b] search request; [c] completed content; and [d] later notification of changes.

    Module 6: Code storage for searcher and content provider

    This module is where the codes are stored. Once the searcher cancels their code, the code is erased and the search is cancelled. If there are other searchers with a similar code, then a single code-cancellation will only apply to a single search.

    User would store search codes on the member tools section of the search platform.

    This module would show the index of searches; users can choose to delete or decline saved search codes. The other half of the code is notified of a change or deletion.

    Module 7: Tagging module

    Clearly the issue will come up with: What if someone does a search, and the content providers are spun up to provide content; then just as they are about to issue a response, the search is cancelled. Then, just after all the data is lost, a duplicate search shows up.

    How will the content provider’s information and tailored search be available for future searchers that arrive after the search request is cancelled? Tags.

    Tagging mechanism will associate a similar search with newly updated content unrelated to a specific search.

    Summary

    This tool is about integrating the XML aggregator with a search engine. But doing far more than simply providing a link.

    It provides real-time updates to content. And ensures the searcher gets the information they need to achieve their goals.

    You now have a roadmap to create a two way search engine. What makes this search engine different than the existing platforms is that it allows content providers to tailor their content to specific search requests. And there’s a follow-up.

    Gone will be the days when someone shows up to your site or feed hoping to find something, and then they leave gone for good.

    Rather, content providers will have a mechanism to translate the original search requests into content updates; and then target this content to the people who are interested.

    Two way searches is about creating a follow-up mechanism. To ensure the search request is filled and the searcher may more likely turn into a subscriber.
    Ever had someone ask you a question, but you didn’t immediately know the answer? As they walk out the door, you find the information.

    Poof! They’re gone.

    Want a way to get in touch with them? Every time someone searches for content and they hit your site or feed, that’s a potential subscriber.

    But what if you have what they’re looking for, but they are not using the same terms you are? It would be nice if there was a follow-up system to give them the information. They might come back.

    Enterprise brainstorming

  • How can content providers engage with not only subscribers and readers, but also those who are searching?

  • How does one create a system where their searches are publicly known to content providers, but their privacy is maintained?

  • How to track the searchers when they come to your site and then have a means to get back with them with content updates after they have left but still protect their privacy?

  • How can information-requests be aggregated so that content-providers can provide targeted responses to those who actually would benefit from the information?

  • How can users create signaling mechanisms that they would like follow-up information on possible future content, without giving away too much information that content providers can harass them?



  • 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 .


    XML Two-way Search

    Publishers giving content later

    Some call it time shifting. Others call it repurposing.

    Another way to look at is: Now that you know what they’re looking for, you can direct them to the more suitable information.

    What could be done is the searcher could permit later contact with the sites she visits. This means providing codes and protocols so that the search platform, content providers, and feed readers exchange information on an ongoing basis.

    Clearly, the protocols would relate to protecting the search, ensuring that the search results and secure, and the search requests are protected and secure.

    Two way search requirements

    A two-way search is something that would given content providers a means to provide information to the searcher. This is a retroactive look, not at content, but at searches.

    The trick to make this work is to have a mechanism that allows publishers to provide content and information back to the reader long after they have left, but still in a timely manner that is useful.

    Unlike the traditional web-searches available today, searchers could signal whether they wanted to have a follow-up-content [not necessarily contact] from the content providers.

    A successful follow-up tool would link content providers only with those who still want the information.

    It would be nice if there was a signaling system that the original information request was fulfilled; there’s no sense duplicating the work of many content providers.

    Once the searcher has indicate the search is over, they could close out the search and the content providers would know that no follow-up is either desired or useful.

    In fact, it would be interesting if the system could also provide other content providers feedback on what content was available or provided that did answer the question. Content providers could either choose to present this information more clearly, or provide signals on more useful sources.

    This tool would connect users-searchers to content; then provide a means for the content-providers to provide targeted updates to the searchers.

    The tool would protect the privacy of the searcher.

    XML Two way searches

    Linking content providers with searchers


    This is unlike PubSub in that it is not intended to continue a search; but do the opposite: Create a means by which content providers can timely provide valuable content to specific audiences that have already requested the information.

    Unlike a pull-based PubSub system, this system would be geared toward content providers who want to push content to those who have already indicated they are interested in certain information.

    Wouldn’t it be neat if the PubSub-like feed codes were available for content-providers? Imagine the bots that could go through that information, solving people’s problems and giving them the tools to achieve their goals. Content providers could have a field day giving people the information they actually need.

    Enabling technology


    Perhaps there could be tools that would permit the content provider and searcher to get into an immediate IM-conference once the searcher has left the site.

    Current IM’s permit this, and there is a platform called BlogChat, but those systems are not focused on searches per se, merely in creating a link between one user and another.

    Enterprise Goals


  • Improves content and information quality provided to customer

  • Convert searchers into readers and subscribers


  • To make this system work, we’ll have to look clearly at what we want the system to do.

    System Goals


  • 1.0 Support current searches

    1.1 Reliably report content for existing information

  • 2.0 Assist searchers with alternatives

    2.1. Makes suggestions on what content might be more useful

    2.2 Lets users know that the content provider can be contacted to provide additional information

  • 3.0 Signaling system to content provider

    3.1 Timely notification from the search platform that the information request continues

    3.2 Identifies the nature of the request

    3.3 Gives a realistic deadline when the content updates would be most useful

    3.4 Provides an estimated time when the search request will most likely be completed and further content updates would not be useful to a particular reader-searcher

  • 4.0 Match content update, search, and requester

    4.1 Method to archive searches

    4.2 Method to associate old searches with new content updates

    4.3 Reliably ensure that [a] the information-content updates are correctly connected to both [b] the correct search request; and [c] the individual requesting the information.

  • 5.0 Maintain privacy

    5.1 Have a secure system permitting readers to get linked with future content updates and changes

  • 6.0 Connection between content provider and searcher

    6.1 Call-back system to link the searcher with the content provider

  • 7.0 Cease work

    7.1 Method to quickly cancel all search requests and block efforts to provide content updates after the search has been completed


  • XML Two Way Tools

    Thoughts on implementation


    The integrated package, platform, and enterprise system would perform a number of functions [supporting goals above].

    Enabling Tools


  • Tool I. Detect searches and site hits [goal 4.0]

  • Tool II. Identify information helpful to the searcher [goal 4.3, 6.0]

  • Tool III. Stores search commands [goals 3.0, 4.0]

  • Tool IV. Identifies news content [goals 2.0, 3.0. 4.0, 6.0]

  • Tool V. Repings or auto-notifies the searcher that [a] new content exists; and [b] a specific content provider has potentially useful information [goals 4.0 5.0, 6.0]

  • Tool VI. Tool would learn from searches what types of search-responses are most likely to address, resolve and help with original search [Goals 1.0 and 2.0]

  • Tool VII. Users would have the option to continue searching [goal 4.3]; set a time limit [goal 7.0]; or decline information and updates for notification [goals 5.0, 7.0].

  • VIII. Platform would anonymously link searcher with search results [goal 5.0]



  • Technical challenges

    Such a system may not necessarily be best supported with XML. There could be a competing or unfolding protocol, standard, platform, or coding capability that could more easily perform this function than XML.

    It remains to be understood whether this type of platform could be best integrated within a more robust server, rather than placing the full burden of the system on XML.

    However, what we do know is that ultimately this type of search system will eventually have to integrate with feeds and the existing XML-related platforms.

    Coding Modules

    This portion of the discussion focuses on the specific tasks that the XML modules might perform to accomplish the two way search.


    Module 1: Detection System

    This would catalog the incoming searching, integrating with Tool I.

    Module 2: Analysis Tool

    This module would look at what information is unrelated to the search, and identify what information was rejected. This would help tailor the subsequent updates from the content provider.

    This module would look at similar searches of [a] the searcher [if available]; and [b] other searches on that content.

    The goal of this module would be to clearly identify the information which the searcher is not getting and content providers may wish to update.

    Module 3: Anonymously link searcher with search

    This module would focus on assigning codes to [a] the user-searcher; [b] the search request.

    This module would create a split code. One half of the code would be assigned to the searcher; and the other half to the search.

    Only the searcher would have access to the searcher’s half of the code. The content-provider would have no way of getting access to the searcher’s half of the code.

    User would have the option to delete the code to terminate the search. Code deletion would signal the platform and content provider that the content update is not intended for a specific user-reader-searcher.

    Other searchers with the same search-request would also be assigned the a similar matching code, but these matching codes would discriminate each content-reader from each other, in a way that no outside person could follow.

    If one searcher cancelled their half of the code, all other searchers with the same search-code would still have a valid search-code-request available for future matching.

    Other searchers would not be able to get access to the identifying search code for an individual searcher.

    Module 4: Generate/Notify

    This module issues commands to ping the searcher, this may be of interest. This module will only fill in ½ of the code.

    This module is the one that works with the aggregators to channel the information to the searchers.

    Module 5: Search Code Generator/Archive

    This module stores information about the search. It gives the searcher a tool to later trade to updated content.

    This is the key interface mechanism between [a] searcher; [b] search request; [c] completed content; and [d] later notification of changes.

    Module 6: Code storage for searcher and content provider

    This module is where the codes are stored. Once the searcher cancels their code, the code is erased and the search is cancelled. If there are other searchers with a similar code, then a single code-cancellation will only apply to a single search.

    User would store search codes on the member tools section of the search platform.

    This module would show the index of searches; users can choose to delete or decline saved search codes. The other half of the code is notified of a change or deletion.

    Module 7: Tagging module

    Clearly the issue will come up with: What if someone does a search, and the content providers are spun up to provide content; then just as they are about to issue a response, the search is cancelled. Then, just after all the data is lost, a duplicate search shows up.

    How will the content provider’s information and tailored search be available for future searchers that arrive after the search request is cancelled? Tags.

    Tagging mechanism will associate a similar search with newly updated content unrelated to a specific search.

    Summary

    This tool is about integrating the XML aggregator with a search engine. But doing far more than simply providing a link.

    It provides real-time updates to content. And ensures the searcher gets the information they need to achieve their goals.

    You now have a roadmap to create a two way search engine. What makes this search engine different than the existing platforms is that it allows content providers to tailor their content to specific search requests. And there’s a follow-up.

    Gone will be the days when someone shows up to your site or feed hoping to find something, and then they leave gone for good.

    Rather, content providers will have a mechanism to translate the original search requests into content updates; and then target this content to the people who are interested.

    Two way searches is about creating a follow-up mechanism. To ensure the search request is filled and the searcher may more likely turn into a subscriber.
    " />