Putting domain names onto data with Fluidinfo

February 23rd, 2011 by Terry Jones. Filed under Data, Essence, Writable APIs.

Internet domain names can be thought of as a mechanism for attaching trust and reputation to digital information. We do this in two major ways: (1) by using domain names in the URLs of web pages, and (2) by putting them in the sender’s “From” address of email messages.

To give a concrete example, suppose you see some shoes for sale on a web page. If you look at the page URL and see the amazon.com or zappos.com domain name, trust and reputation knowledge springs instantly to mind. You know the quality is probably good, the price competitive, and that if the shoes are lost in shipping you’ll be sent another pair for no charge. On the other hand, if you see ebay.com in the URL, a different matrix of trust and reputation knowledge will spring to mind. A similar thing happens if you get email from someone you’ve never met. If you see stanford.edu or forbes.com in the email “From” line, reputation information springs to mind.

Looked at in this way, domain names are small tokens that we send alongside other pieces of content such as web pages and emails. The domain name carries vital trust and reputation information. Recognition and trust in domain names is globally distributed, spread variously through the brains of most of the people on the planet, with its integrity guaranteed by DNS. Domain names make the internet useful. Without them, digital information online would be almost useless as we could not confidently trust any 3rd party data.

Question: given that we can attach domain names to web pages and email messages, can we find a way to attach them to other things?

Domain names on data

We’re excited to announce that Fluidinfo now makes it possible to put domain names onto individual pieces of data.

To illustrate, the image on the right shows a fanciful example book object in Fluidinfo (large version). The tag names on the object are colored. You’ll see that some of them contain domain names: amazon.com/price, barnesandnoble.com/price and vintage.com/epub. Tags in Fluidinfo can have values, as illustrated by the amazon.com/price tag whose value for this book is $19.

The combination of a Fluidinfo tag name containing a domain and an associated tag value is exactly like a URL containing a domain name and an associated HTML value (i.e., a web page) or an email message with a domain name in its From line.

Because Fluidinfo objects don’t have owners (their tags do, though), any number of domain owners are free to put their information, branded with their domain name, onto any Fluidinfo object.

A killer combination: writable APIs with domain-branded data

Fluidinfo automatically provides a writable API for all its data. By allowing for domain names on data, domain holders who want to publish information about their products can now do so with an API that has three major advantages:

  • Your data is branded with your domain name.
  • Your data lives in a writable ecology of related data, collecting on the same Fluidinfo objects. This allows for search across data from different users and domains, put there by different applications. It allows for additional data of all kinds, for mashups, and for customization, personalization, and filtering.
  • Fluidinfo has a flexible permissions system at the level of its tags, so you maintain full control of your own data. You can make it public or private, or can allow or disallow access for specific others.

Because Fluidinfo objects are fine grained, composed simply of tags with values as in the image above, applications can fetch, search on, or combine specific pieces (or combinations) of data provided by different trusted sources with single requests. There is a general principle here: information becomes more useful and valuable when it is stored in context. This is illustrated vividly by Google, which collects web pages into one place to enable search, and by Wikipedia, which allows people to pool related information. Although these examples have very different models of trust and reputation, they both illustrate the underlying principle.

Getting your domain name in Fluidinfo

To start using your domain in Fluidinfo, first sign up, using your domain name as your user name. Our sign-up system will recognize that the username is a domain and will send you an email telling you how to prove that you control the domain. Once that’s done, you can begin using Fluidinfo to upload information branded with your domain and to provide an API for others (or for your own company) to find your products or otherwise use the information you make available.

In other words, all Fluidinfo usernames that correspond to actual internet domains are automatically reserved for their owners. Besides preventing a chaotic land grab, this is how we can guarantee to people seeing information in Fluidinfo that the value of a Fluidinfo tag whose name includes a domain name can be trusted exactly as it would be if that domain appeared in a web page URL or email From address.

So there you have it… domain names on data. We’re very excited to see where this will lead and we’re actively building out some writable APIs with domain-branded data. You can too. Claim your domain name in Fluidinfo right now.

This entry was posted on Wednesday, February 23rd, 2011 at 11:15 am by Terry Jones under Data, Essence, Writable APIs. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • http://vocal.ly sull

    Congrats on this exciting and brilliant announcement. :-)

  • http://Twitter.com/Ed Ed

    Great work, Terry! I have some ‘domain science’ friends who want to speak.
    I’ll dm you tomorrow. Darn time zones! :)

  • Pingback: pinboard February 24, 2011 — arghh.net

  • http://iwantmyname.com Timo Reitnauer

    Interesting stuff! Just signed up with a domain name and received a confirmation email asking to create a HTML file. Any plans to offer DNS verification via TXT records? Would be much easier in most cases.

  • http://blogs.fluidinfo.com/terry terrycojones

    Hi Ed. I only just saw this comment. I’m terry fluidinfo com in case you’d like to mail.

  • http://blogs.fluidinfo.com/terry terrycojones

    Hi Timo

    Yes, we plan to offer other mechanisms. Google sites uses (IIRC) a CNAME record. Do you know why they do that instead of using a TXT one? Maybe CNAMEs are just more widely used or accessible via simple web interfaces for maintaining an SOA record?

  • Anonymous

    Just reading about Fluidinfo today, so sorry if this is obvious but why wouldn’t the tagging convention be something like “price/amazon.com $19″ and “price/barnesandnoble.com $18″ – seems more obvious to me as a means of finding all pricing info about this object in this way?

  • Anonymous

    Just reading about Fluidinfo today, so sorry if this is obvious but why wouldn’t the tagging convention be something like “price/amazon.com $19″ and “price/barnesandnoble.com $18″ – seems more obvious to me as a means of finding all pricing info about this object in this way?

  • http://blogs.fluidinfo.com/terry terrycojones

    HI locomomo

    The way Fluidinfo works is to have a top-level namespace for each user. In your suggestion, the “price” top-level namespace is being used, and this would typically have just a single owner. Someone *could* get that username and do exactly as you say, but then they’d have to be tagging objects with the prices from various companies. People could then choose whether or not to trust/rely on those tags. The other way around, it’s the companies that take their own domains, and they already have the trust that comes with their domain. That way the work is distributed and you get the trust & reputation from the actual domain holders.

    You’re also suggesting putting the price into the tag name (I’m not sure if you’re doing that on purpose), e.g., with a tag named “price/amazon.com $19″. That could be done too, and perhaps some people will chose to do it that way. But Fluidinfo allows for tags with associated values. So a different approach is to have a tag named “amazon.com/price” and put that tag onto different objects, each with a value accompanying the tag. Done that way, you can better use Fluidinfo’s query language to find objects of interest, via e.g., amazon.com/price < 20. When the value is separated from the tag name and has a type, you can get at it with a query. Tags with values & querying allows sophisticated applications to be built and is one of the big differences that makes Fluidinfo more than a traditional tagging system.

    I hope that makes things a bit clearer. Please feel free to ask for more help / examples, etc.

  • Anonymous

    Cool – thanks for the quick answer. Yes, I think I meant to use “price/amazon.com = $19″ rather than putting the price into the tag name.

    This gets at a couple more thoughts regarding this example – so if I’m writing something that compares prices of books in fluiddb how can I programmatically “discover” all of the price related tags on a given object? Is the idea/hope that certain tagging conventions would emerge? What if B&N adopts “barnesandnoble.com/cost = $18″? How will fluiddb deal with issues that arise in other free-tagging environments like homonyms and synonyms, etc. ?

    With the “wiki” metaphor you’ve mentioned elsewhere, one thing that makes Wikipedia easy to use is that in addition to being writable, certain general conventions are followed in the structure of the data on the page. Do you imagine these developing organically or with guidance by FluidInfo?

  • Anonymous

    Cool – thanks for the quick answer. Yes, I think I meant to use “price/amazon.com = $19″ rather than putting the price into the tag name.

    This gets at a couple more thoughts regarding this example – so if I’m writing something that compares prices of books in fluiddb how can I programmatically “discover” all of the price related tags on a given object? Is the idea/hope that certain tagging conventions would emerge? What if B&N adopts “barnesandnoble.com/cost = $18″? How will fluiddb deal with issues that arise in other free-tagging environments like homonyms and synonyms, etc. ?

    With the “wiki” metaphor you’ve mentioned elsewhere, one thing that makes Wikipedia easy to use is that in addition to being writable, certain general conventions are followed in the structure of the data on the page. Do you imagine these developing organically or with guidance by FluidInfo?

  • http://blogs.fluidinfo.com/terry terrycojones

    > thanks for the quick answer.

    And thanks for your interest!

    The idea/hope is very much with the emergence of conventions. I really don’t like ontologies, at least not if that’s the bottom level of a system. In Fluidinfo you can layer ontologies on top of the underlying system if you want to, but nothing is imposed. That’s a plus and a minus of course. I like evolutionary systems, and believe that selection pressure will cause things to converge (i.e., remove ambiguity etc) to the extent that’s useful / necessary. Of course one can help the process along by encouraging conventions & setting precedents. Also, popular applications will set precedents that will be followed. I think it’s very important that no-one *has* to follow the prevailing conventions, it’s always a choice.

    As for finding tags, there is an object in Fluidinfo associated with each tag (it’s the one that is itself tagged with fluiddb/tags/path = amazon.com/price). That gives a place to put information about that tag. Without being able to say what the information on that tag should be, it at least provides a place where information about a tag can be stored, discovered programmatically, etc. You could also find such tags by matching on the fluiddb/tags/path tag (looking for values that match the regular expression .*/price$ – though you can’t do that today, we’ll turn it on soon). Another possibility is that tags can also be given a description, and you can search on descriptions (there’s no assurance that what you find will be reliable or even a price (“price” might mean something else in another language, etc)).

    None of those may seem very satisfactory. I think the first of them is the one where there’s most potential for a useful convention: e.g., Amazon puts an amazon.com/tag-type tag onto the object for the tag amazon.com/price (the single object satisfying fluiddb/tags/path = “amazon.com/price”). They follow the convention that the creator of the tag puts a USERNAME/tag-type (with appropriate contents) onto their own tags to indicate what they contain. That heads towards programmatic discovery.

    There’s the domain name reputation system above. People (and programs) can just be aware of certain price tags that they trust, or come to trust. This is word of mouth, and that knowledge can be embedded into programs just as it is into people’s heads. Again, that may not be a very satisfactory answer.

    Finally, a 3rd party may decide to add tags to the objects for tags, and set themselves up as a trusted authority on tag types & reputation.

    Thanks again for the questions. I don’t know the answers to these things, I only have ideas and the certainty that the writable nature of Fluidinfo (along with its other qualities) means that there are several ways an answer can be arrived at. We also have to make sure that the evolution of these things happens on a start-up timescale, not a geological one :-)

  • Anonymous

    ok! .. lot’s to chew on here, thanks.

  • http://profiles.google.com/gpickett00 George Pickett

    Terry,

    I think I understand this concept 80-90%. I’m not a programmer, just interested in tech in general. I watched your demo at “launch conference” on justin.tv and didn’t understand your company, but researched more. I think you do a better job describing how it works and why it’s useful on this post, “Putting domain names onto data with Fluidinfo.”

    However, to reach a wider audience I think you need to continue to work on making this easier to understand for the “average Joe.” Maybe you could just create a bunch more of those images like you created with “book info.”

    Another thing to make it more clear would be to give us a vision of what your company would be at its ultimate success. If everyone in the world understood and used Fluidinfo, how would this look? How would most people use it? How would people benefit from it? In my opinion, giving a vision of your future success would help me to understand why this is bound to be the next killer app. I’d love to hear your thoughts on this. Thanks

    George

  • http://es.photoswomens.com Solteras

    Thanks for such an informative article, it’s been very useful.