After proposing the idea of the SMBmeta Data File, it became clear that there are other elements to the "ecosystem"
necessary to bring this all about. This essay is a first pass at describing some of those pieces. As SMBmeta data becomes
more common, there will surely be other element that will arise.
The Main Components
In addition to the smbmeta.xml file stored in the root of each small business web site, there are other components that
seem to be necessary to get this all going. There is a diagram, below, that shows how these components fit
together.
The components all relate to a Directory or Application that wants to create a database of SMBmeta data
and make use of that data for some purpose, such as responding to human search queries.
The first component is the "SMBmeta Registry". An SMBmeta Registry is a server that will, upon request,
return a list of domains and the URL of web sites on them with SMBmeta data. The purpose of an SMBmeta Registry is to make
it easier for applications to find domains with SMBmeta data, so that one does not need to always spider the entire web.
The second component is the "SMBmeta Proxy". An SMBmeta Proxy provides the same data one would find
in an smbmeta.xml file (i.e., a <business> element with sub-elements) on behalf of an existing domain and web site.
An SMBmeta Proxy can hold the data for any number of domains. It is up to the Directory or Application to determine how they
want to use this information. Sometimes, the proxy information is only used if there is no smbmeta.xml file on the
web site itself. Sometimes the data in the proxy may be considered more "authoriative" than the web site data (if it exists).
The existence of proxies can help jump-start the adoption of SMBmeta data by letting existing databases be used to "prime
the pump" until enough web sites have the data on them.
The last component is the "
SMBmeta Affirmation Authority". An SMBmeta Affirmation Authority is
a server that will, upon request, return a value associated with a particular domain. An SMBmeta Affirmation Authority is
used to provide information that may be helpful in determining the truth of the data provided on the web site. For example,
the Authority could indicate that the requested domain's business type is known to be correct (a "good" list), or
that the requested domain is known not to be anywhere near correct (a "bad" list). A Directory or Application could
check on the domain's data through a query of the Authority, or use the optional signature to check algorithmically on
the authenticity of the claim of being affirmed. (See the
SMBmeta and Spam essay.)
The relationship among the parties
Each of the components may be unrelated parties. The relationship among them is up to the parties themselves. For example,
there can be any number of registries, proxies, or Affirmation Authorities. Whether or not a given Directory uses them is
up to Directory and the registry, proxy, or authority. There may be costs involved to have access to a particular registry,
proxy, or authority. Like many web services, the access may require an ID and password, or other mechanism.
A diagram showing how this fits together
