I forgot to post a link to a nice "How To" article that featured SMBmeta on Webmonkey: "Metadata, Mark II" by Jason Cook. The part about SMBmeta is on page 4.

 

Jean-Yves Stervinou built an application that reads the Registry data on SMBmeta.org and makes a list of entries as an outline in OPML format. From the smbmeta.xml file he gets the business type and uses that at top level, other information at a lower level. Two open formats, used together. Very nice! See When SMBmeta meets OPML.

 

Finally. After lots of work, I have a complete sample SMBmeta ecosystem implemented and running for public viewing. (I'm assuming that anyone reading this has read the Proposed SMBmeta Ecosystem essay.) Here's what there is:

 

On the new website www.overall.com, there is a simple directory of businesses with SMBmeta data files. It can be searched by gross NAICS code, postal code, and country. It shows some of the ways listing can be done. That directory gets the list of domains to display from the ones added to the Registry on www.smbmeta.org using the Registration Utility tool. It is filtered through a simple Affirmation Authority run on overall.com. The pieces communicate using an XML over HTTP API. It is all documented in "SMBmeta Application and API Examples" on the smbmeta.org website. This is not a "real" directory, but should be useful in its own right until something better comes along from someone else. (The domain was one we had at Trellix for many years and now belongs to Interland. The trademark "Overall" is for a product that has a database, especially with spatial characteristics, which sure fits a postalcode-searchable directory of businesses.)

 

The Perl source code for all of this is also available on smbmeta.org. I'm not that experienced with Perl, and I'm sure there are lots of problems with the code. Let me know if you find any really bad ones so I can fix them.

 

The specification for the smbmeta.xml file on this website is pretty complete with version 0.9. Any future tools should be upwards compatible. It is now time for people to create smbmeta.xml files for small business domains and register them. It is also time for those that are interested to experiment with the system, perhaps implementing their own versions. Anyone who starts development should contact us here (send mail to "webmaster") and we'll give you an ID for querying the various databases using the API.

 

Also, a new article about SMBmeta from Jamie Lewis of the Burton Group came out a few days ago.

 

Thanks to all of you who have been helpful in getting this far.

 

-DanB

The last few weeks have been very busy for the SMBmeta initiative. I've been talking to lots of different parties, from search engine companies to domain registrars to Internet Industry pundits, in order to move the initiative ahead. I've also been attending conferences, making pitches. In the process, various components that would make up the "ecosystem" necessary to get adoption going of SMBmeta Data have become clear. In addition, I've been programming working prototypes of these components to help the development of proposed APIs. I've also added the <affirmation> element to the Version 0.9 Proposed Specification. It's all continuing to be very exciting.

 

At this point, I have a new essay about the proposed ecosystem, complete with a diagram. I also have initial working protoypes of a directory, a registry, and a proxy, and have been running them against real SMBmeta files out there in the web. Soon, I'll have an Affirmation Authority, too. At that point, when it seems to all work (which will make it easier to stablize the APIs), I'll publish the source code and open up the prototypes to the public for comment.

 

-DanB

Listening to a lot of the feedback, and looking at sample SMBmeta files created by various companies around the world, I've updated the SMBmeta Specification, releasing Version 0.9. This should be nearly complete. It includes the <coordinates> and <accessibility> elements I mentioned previously. (The one area left will have to do with affirmation, where some other web site vouches for some of what you put in your SMBmeta file.)

 

To go along with this, Version 1.1a of the SMBmeta File Creation Utility was released on www.smbmeta.org. The version 0.9 SMBmeta file format is upward compatible with the original version 0.1, so old smbmeta.xml files do not need to be updated.

 

In addition to this, I've been doing work to prototype other parts of a full system that takes advantage of SMBmeta, including a sample registry, proxy, and aggregator. Once they are done and preliminary written specifications done, I hope to post them for comment. At that point, it should be clear what you would need to do to support SMBmeta in different ways.

 

Thanks to everybody who has been helping this Initiative get this far. It's been very exciting.

 

-DanB

Esther Dyson wrote an article about SMBmeta for her New York Times Syndicate column. It's called "Build It And They Will Come".

It has been suggested that a normal link to the SMBmeta file would be helpful to let it be more easily found by normal search engines. The file format lends itself to normal indexing. What would be helpful would be a standard way of linking to the SMBmeta files. I propose one in the SMBmeta Button essay.

Yutaka Furubayashi, from the University of Cologne, Germany, has written a RELAX NG Schema describing the SMBmeta file format based on the Version 0.1 specification released so far. RELAX NG is written in XML and is a popular (and somewhat readable) way to describe XML data. There have been requests for a DTD for SMBmeta to help validate files, and hopefully this will help with those needs. You'll find a link to the schema and links to a RELAX NG tutorial and other resources on Yutaka's SMBmeta 0.1 Schema page. Comments would be appreciated.

I've added an essay about SMBmeta and search engine spamming. It includes a discussion of how SMBmeta differs from the old Keywords meta tags. See SMBmeta and Spam.

I'm working on a few things for which I need help from others.

 

First: I'm doing an update to the spec based on feedback. There are two new elements I'm thinking of adding to address physical location and accessibility.

 

We need an optional element like "<coordinates>" that specifies lattitude and longitude for a <location>. While I don't want to force people into giving out their specific location (just as their physical address is optional), there are many ways in which having lattitude and longitude would be helpful. The <address> element is supposed to have information sufficient to get the coordinates, but having it already encoded may be more reliable. Anybody have some ideas who has experience in this area about what type of values and links to give people for finding out that information?

 

For accessibility I'm thinking of something like an <accessibility> element with attributes like "stairs=number of steps to get in and get around", "elevator=yes/no", "ramp=yes/no", "platformList=yes/no", "accessibleParking=yes/no". Also, maybe an attribute for TDD. Could somebody with experience in this area contact me to help?

 

Secondly, I'm working on some essays. The first will deal with Spamming. I see a few issues here, such as a taxonomy for the type of "spam" this system will lead to (e.g., showing up in a search for which you are inappropriate, such as porn in a search for a home builder, and giving false information about your business to raise your position on an appropriate search). There are the methods aggregator/search engines can use to minimize spam. Finally, there is what we can do to modify the specification to catch or invalidate such activities. Ideas would be welcome. (The idea of third-party "certification" has already come up repeatedly and I'll address that.)

 

Use the "webmaster" at trellixtech dot com email address for comments. Thanks!