Show HN: Business.txt - Standard Proposal

Having said that I also believe that a txt file is way more easier than schema for the rest of people who can edit a file. That txt file is done in minutes, the schema file is done in hours :P

What i feel necessary are 2 things:

- Having a separate file

- Doing something that the big websites support so we can "sell" to local businesses.

So if more people believe we should extend schema instead of going with txt, we can work on it.

My experience with small business clients is that they have no idea what they are doing when it comes to the web. They tend to know exactly what they want, and are usually right. But, they don't know how to translate that to their sites. Usually, it just takes a bit of guidance.

Creating a proper about page for a site that implements schema.org standards makes sense for both the developer and content creator.

They even provide an example for an organization here: http://microformats.org/wiki/hcard#Parsing_Details

It looks like by default, it only intends to have one url but adding more should be as simple as adding a rel type to give some context around it.

Instead of generating errors from 404s (a lot of noise), try generating errors from the same repeated 404s.

The owner of the local business is the one who knows which is the correct address, phone, opening hours, menu, etc. All the other websites (yelp, foursquare, google places) can be wrong. We just need the local business to tell the rest of the world which is the correct data.

[1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

[2] http://infiniteundo.com/post/25326999628/falsehoods-programm...

Google places is good but I doubt Yelp does anything, for example, and a ton of other sites. And most people don't even know to trust google places more anyway, they'll just trust the top result on google.

PD: i hate when we have to complicate things because of bad human behaviours!!

You're right. No research was done. Author just threw information that he thought was important into a text file and called it a day. RFC 5785 says to put the file into the .well-known folder, the author only thought about United States addresses when making this, and as you stated the problem has already been addressed.

Please don't take this the wrong way, since I think it's great that you are thinking about these problems, but :

It's not clear what advantage your format offers. On the other hand, it has some pretty clear disadvantages, including generating massive amounts of possibly useless web traffic, not just on the server side, but on the crawling side, since now getting business info takes two requests, instead of one (when it is embedded in a schema.org format on the page).

Additionally, without some tag that tells you whether business.txt would exist, you get to check for every website. This will slow down crawlers.

Given at least most of the companies on the crawling side of this want to support/support the schema.org markup version, ISTM you would be better off spending your time making simple generators for it or adding support for it to wordpress/et al.

FWIW: I have no comment on whether text formats are better than schema.org or anything like that, but to a large degree, it's irrelevant, because getting a large number of folks to support something they believe is already a solved problem is very very difficult.

1. I wrote in another comment here (ctrl+f) but there's overlap with other standards. One of our main multi-million EU projects was about seamless integration of different standards for representing information about resources (i.e. details of a factory) when integrating between very large entities (i.e. BMW and Honda). It was more on the mathematical/computer-science side than technical (i.e. not "Is some path for business.txt better than others"). When two IT departments/armies of consultants use different standards for everything from Address to TaxReceiptCode and you try to integrate it's ugly. When it's a large N of such, you need multi-million EU-sanctioned research projects. Moral of the story: please use standards. That said:

2. There's definitely a turing tarpit[1] situation with RDFs and RDF Schema(s). As you said on github, "Other local businesses may think on adding to their website some metadata (using http://schema.org/). The problem is that it's too complicated for a non-developer". The best standard is the one being used instead of being forgotten in an hundred pages design document. If you find yourself thinking about the problems RDF (and schemas) tries to solve, please take into consideration a clear and standard one-to-one conversion between the specification and some other more established and expressive specification. For example, define an RDF Schema and a clear conversion between RDF using that schema to and from business.txt. The main benefit for the project if you take such a conversion into consideration while designing the document is that it promises a clear way for future spiders to interpret the data regardless of expressiveness and may give the more knowledgeable authors of such document that more expressiveness, where needed. The default should be clear and easy. Case in point:

3. People here commented how the address format is very American. They are right. But for ease of use, maybe the default should be American and add an option to explicitly express the address differently (i.e. different administrative entity than states) and let there be a canonical conversion to something like this, including a way to explicitly express the address using something like the Freebase schema for addresses[2]. Notice how complex are the types for the different fields, like State/Province. This is because encompassing an Address entity globally is a complex problem. Heck, in some countries usage of place descriptors ("fourth junction after the main entrance to town") is still common. I once read some research paper on it, but it eludes me at the moment.

EDIT: 4. Some people here say what's the use. I'm sure you can address this better than myself, but the main "selling point" for me is the ease of use. The focus should be on very easy defaults. Properly defining namespace URIs or microdata itemtype for example is already error-prone/requires too much thinking for the general user. I do think there may be a room for this project.

That's it for now. Too much long of an HN break as it is :-)

[1] http://en.wikipedia.org/wiki/Turing_tarpit

[2] http://www.freebase.com/schema/location/mailing_address

about rich snippets, go to http://news.ycombinator.com/item?id=4438320

Also, we are following the same pattern as the robots.txt file.

Have you ever written a SAX parser? XML parsing is not "easier". Screw the libraries that "do it for you". You still have to understand the tiered data structure, attributes vs content, namespaces,.... the list goes on. Understanding the schema and all that jazz is WAY more difficult than key: value.

edit: Parsing is just as easy. Here is a one-liner in ruby:

business_data = IO.readlines("business.txt").each_with_object({}) {|l, memo| k, v = l.split(':'); memo[k.strip] = v.strip }

This is why I like the business.txt idea. Microformats or microdata, however appropriate and simple, are still one level of abstraction above this idea.

I came to this post 45 seconds ago, looked at GH, and could explain what this is for and how it works. That's saying something.