This may not be a totally revolutionary idea, but it’s something I’d love to see implemented. The end state of the proposed application would be to deploy what I call a “Semantic Servant” that provide guidance for searching and indexing. I’m terming it a “servant” rather than a “server” for the basic reason that I see it as a “helper tool” to existing servers rather than serving up content itself.
Without getting into it too deeply, the concept is that the Semantic Servant (via a new “Semantic Servant Index Protocol”) would reply on a specified port to provide a machine readable summary of the content available from another server. For example, if a web site is available at “http://www.contentsite.com”, the servant would reply on the same URL via something like “ssip://www.contentsite.com”. The results would be an XML packet including rules for leveraging the content on the sister site.
Keep in mind that this is a totally half-baked idea. My goal in this concept would be to empower a website developer with a tool that would, with a few minor configuration clicks, tell spiders/bots/indexers/etc. more about the associated site. In order for this to work, the servant application would have to be incredibly light weight and easy to use out-of-the-box. Assuming the servant defaults to a standard OWL, RDF, etc. standard configuration, the administrator could select from some pre-canned configurations and let it go.
The more time the administrator spends customizing the configuration, of course, the more fine-tuned it could be to the content of the specific site. In this way, though, indexers visiting the site would (a) have more information about the content of the site than is currently (easily) available, and (b) changes to the site would be more forgiving.
This is, of course, assuming that producers of web content want their information to be aggregated more freely. If a site producer wants to force all of it’s users to it’s front gate, this isn’t the solution for them. As I think we’re moving to an “All Content Everywhere” model, though, whereby there are multiple ways to experience the same content, I see something like this as an eventual must-have.
Semantic Servant
This may not be a totally revolutionary idea, but it’s something I’d love to see implemented. The end state of the proposed application would be to deploy what I call a “Semantic Servant” that provide guidance for searching and indexing. I’m terming it a “servant” rather than a “server” for the basic reason that I see it as a “helper tool” to existing servers rather than serving up content itself.
Without getting into it too deeply, the concept is that the Semantic Servant (via a new “Semantic Servant Index Protocol”) would reply on a specified port to provide a machine readable summary of the content available from another server. For example, if a web site is available at “http://www.contentsite.com”, the servant would reply on the same URL via something like “ssip://www.contentsite.com”. The results would be an XML packet including rules for leveraging the content on the sister site.
Keep in mind that this is a totally half-baked idea. My goal in this concept would be to empower a website developer with a tool that would, with a few minor configuration clicks, tell spiders/bots/indexers/etc. more about the associated site. In order for this to work, the servant application would have to be incredibly light weight and easy to use out-of-the-box. Assuming the servant defaults to a standard OWL, RDF, etc. standard configuration, the administrator could select from some pre-canned configurations and let it go.
The more time the administrator spends customizing the configuration, of course, the more fine-tuned it could be to the content of the specific site. In this way, though, indexers visiting the site would (a) have more information about the content of the site than is currently (easily) available, and (b) changes to the site would be more forgiving.
This is, of course, assuming that producers of web content want their information to be aggregated more freely. If a site producer wants to force all of it’s users to it’s front gate, this isn’t the solution for them. As I think we’re moving to an “All Content Everywhere” model, though, whereby there are multiple ways to experience the same content, I see something like this as an eventual must-have.
… then again, I’m a dreamer.