VRM Hacker Session
VRM Hacker Session in London, November 9th Attendees: Doc Searls, Ben Laurie, Duncan Cragg, Alec Muffett, Alan Patrick, Alan Mitchell, Iain Henderson, Dave Shaw, Adriana Lukas
the minimum requirement - flexible enough to built on top of it
* structured goop, * two way links, and * access control
-> that's the infrastructure level
underpinning of vrm is structured goop, two way links, access control
Alec's comments in italics throughout the document:
what is the minimum technical requirement that we can specify to create one or many different VRM tools?
we suspect that we will need:
an ontology to describe purchases, objects, anything ... (slang: "structured goop", existing in "blobs" - probably XML)
a syntax and means to describe bidirectional links between objects (so that B knows it is a child of A, and A knows it is a parent of B) access control of some sort
where do you draw line, single ownership objects and then what we will see is a construct made of lots of single ownership objects
there is an open issue of object ownership; whether a data object ("blob of goop") can/should have multiple owners at a given time
what you do â make any progress- ontology
I want wifi on the plane, how do say that â has to be machine readable
does it have to be machine readable from the start?
the ontology challenge could be huge; for instance if you want to describe that a particular airplane journey provided wifi, how are you going to define that in a machine-readable manner? it would seem impractical to expect some committee to create a series of pre-ordained flags to be create which can describe everything the user wishes to describe. can we / should we ignore the issue of machine-readability at the outset, or might it be better to leave the matter of description open, eg: by designing space for a folksonomy of tags, or some other open-ended means of description?
Next question â how do you express what you want? Objects, data
smaller subdivisions â what's in it
structure â tools UI stuff, it has to produce something
make the UI unstructured but the underlying data structured
some data should have meta data â book has ISBN
QR codes â idea
agree piece of structure,
suck this info into my database
support rich data structures â will arrive by consensus, book author, date of publication, ISBN
when it comes to absolute description of objects, or (more concisely) "binding" a blob of goop to a specific object, then the obvious thing to do is leverage ISBN codes, UPC/Barcodes, and other unique identifiers like those which exist in the real world; referencing them either directly, or in some coded format (XRI?) in the blobs of goop.
click on a page of restaurant and see who from my network commented on it â I want a handle on what they are saying, filter - meta data that says stuff about the data, so I can look at it and context
we imagine that VRM tools will be able to draw together the many blobs of goop which reference the same objects, eg: the many reviews (each, a blob) which refer to a specific restaurant; the tools will provide the ability to search and collate, aggregate and present these blobs in an accessible manner.
* two-way links: protocol for referencing data â http or something â micro web
highly rigid two ways links to stick, URI vs URL
freenet, mutual pointers between pieces data, common information about things, Doc's fave example travel, hotel - my representation of the hotel links to Adriana's representation of the hotel.
The price we pay for distributed information/data not platforms?
the "blobs of goop" are an atomic data format, they should be able to be exchanged and manipulated without dependency upon other larger data structures; however there will likely still be a need to represent hierarchical relatiopnships between blobs; since the objects are atomic, their parent/child hierarchical relations need to be cited in both objects, ie: bidirecionally; a parent cites its children, and a child knows its parent.
Open APIs don't solve the cross-system links? Duncan's point about presentation at google on 8th November
We are taking data away from the silos but the same issues will be there â distributed access
OpenID â works on multiple sites, profile level,
selective disclosure â trusted entities, two proofs are linked together
* structured goop: ontology (Dewey decimal system) [is an example of] how we talk about any subject (eg: wine), assuming creation of an agreement, common understanding or framework for the data, less than language, way of dividing and classifying data, so we can communicate â machine readable => we have to agree that how to express data/facts about a thing
cloud of all variables generated by centralised system but by users
in other words there is an easy way to create a "blob of goop" without requiring some committee to create a DTD which describes the comfort of an airline flight; instead the "blob of goop" is just a container that is described by a bunch of tags which evolve under a folksonomy, ie: are neither pre-defined nor bounded. An interesting concept which arose during the meeting was that a blob could - in addition to the tags which describe it - could contain a "payload" of data held in whatever microformat is most convenient and popular to contain the pertinent, object-specific data. "Blobs" would thus become ubiquitous wrappers for exchange of data payloads (in arbitrary formats) whilst tagging them for indexing, retrieval and to cite authorship, etc.
XRI guys will be at the event in california
extra layer of problem, we are going to define this system of categories, we'll do is pass around tokens and someone else will define it for you â meta data
categories for various objects/data
humans can deal with multiple frames of reference â but computers need a more unified frame of reference
too many things to describe
ontology will emerge? [ie: folksonomy]
Personal RFP? Number â looking it up on the website, I want that
here's a verbal description, clunky
looking for video camera on ebay â different spellings, hyphen
As ever, the challenge to finding what you want on google, ebay, etc, is to work out how someone else will have typed the name of the thing you want - TRV900, TRV/900, TRV-900, TRV900E, ... are all the same video camera, but only if you are a human being who can weave your way through the ambiguity of different naming; some means of disambiguating product lookup would be really beneficial to online purchasers...
something very discrete â looking for something specific, not search query
if a vague search query marketers will crowd in and promise to find you something like this and all your friends will recommend!
Start with specifics â car parts that deal with it, centralise info and email you back
[ie: the story about companies which exist and add value by presenting a single point of contact to a bunch of junkyards; the company will forward your request for (some specific auto-part) to a bunch of junkyards, and let you know who can supply it for you; the junkyards benefit because they get specific queries phrased in terms they can understand, the buyers benefit from saving time; this also happens in the secondhand book market ]
Harvard business schools â MBA students who came back to school â remake the car industry from customers side
social web thing â I don't want to enter what I know about hotels, cross-silo standardisation
no federation across silos
point of integration, the patient is the best side
at the dispersal side â multiple providers, any personal information, that needs to be formalised
is it pull or push?
Define VRM as a social network?
Creator of Jabber â Jeremy, approach to search â distributed way
DTD â template, name, location, price, tagged
CRM it's minimisation of information
high speed internet or not in hotels â tags that orbitz can pick up
four airlines got together â competed with travelocity and expedia
every hotel has its own CRM system â communications are very screwy
different things about connectivity
turn obsessives into search â architect a data system
in long run we need is a common practice, community of practice â mini-communities
how we do routinise, the activities of individuals coalescing about specific activities
first order is you contributing to order and find the hotel I want, how that finds its way into a formal system, that's big enough to call market place and how to change CRM systems to give you more granular information
Open social â trying to do the same thing, sneak that stuff into VRM
the architecture â I belong to many things or want to relate, doesn't have to be linkedIn, Facebook or MySpace but it can be Doc's space or Adriana space
Facebook is evil, facebook mark up language â the old silo, lock-in trick
Proof-Of-Concept Thought-Experiment: create a human-readable microformat to describe a (for instance) hotel stay; get lots of people to post their review (using this microformat) to their existing blogs as standalone articles (blobs of goop) ensuring they tag the postings appropriately, including the tag HOTELVRM. Use Technorati/Google to access, aggregate and search all HOTELVRM postings in the entire world, and a custom AJAX application to present the microformat data in a more attractive manner. Object interrelationships would be implemented via "trackbacks" and comments could be added to the original posting. You would never want to /do/ it like this, of course, but the above gedanken demonstrates the some of the desirable traits - sharing, syndication, aggregation, search, tagging folksonomy (SHERATON, HILTON, SMELLYROOM, BADFOOD, GOODSERVICE) etc... You are mostly missing access control.
the moment you control your personal data â how you get the data shared, how to get ben and alec excited, we have to talk about how to stop it from being shared
the best way to predict the future is to prevent it [Doc quoting someone else]
we are not codifying beer or wine or car part, we won't see wars like around RSS
what are we going to talk about â if the market is going to do that, what's the easier way to do that
answer â reuse shit
P2P, microformats, people, reviews, calendars
user at the centre of the whole thing
if you want to leave it to the market?
Bottom up, people know stuff already you are getting them try to describe it
how about using micro-format for a car part website
nuggets of informations, micro-formats?
Don't sit down with OASIS
viable conversation between Alec, Alan P and Duncan â ask about later!!!
encoded blobs â can you stop that working?
Alec: I think there are three major ways to address the matter of "blobs" ontology - what they should look like, and what they contain:
1) throw the whole thing over to committee, to come up with new DTDs to describe each and every thing VRM might ever want to describe. <object class=teaspoon metal=silver style=baroque,ornate /> 2) create a "container" format which exists mostly to provide structure to tags which are created by the users, pure folksonomy (<tag>spoon teaspoon silver pretty spooooon baroquespoon</tag>)
3) as for 2) but make space to employ pertinent microformats.
<comment>i really like this spoon, i am heartbroken to sell it</comment>
<payload format="uSpoon(Antique)1.0" encoding=raw>
...my personal bet is that the answer lies between numbers 2 and 3, and that number 1 is impractical. If microformats exist, then reusing them makes sense as the communities of interest will see VRM as a way of querying, swapping and discussing their favourite things.
Doc likes the fact that "long get" is involved in Micro Web â two stage transaction
medical records â form I get as a copy, scan it, card that points to a database
trusted places, surgery, hospital â health authority â custody
disclosure â allow not for profit social enterprises
nobody will trust a profit company
standardised or common way of gather data â this is what you bring to the hospital
product IB â patient needs to be the point of integration for multiple treatments, devices and product
they are siloed in diabetes â take a disease
create the receiving end of VRM organisation â couple of employees tasked with creating with interface
integration â reasonable set of variables facing a patients, list of all things that are JNJ and that are not JNJ
helping the patient formalise to be at the centre
inclusive of doctor-patient relationship
geriatric medicine some VRM mechanism that makes it easier for patient and his doctors to integrate all that records and data
having the patient at the point of integration â from one department to another without any communication â that's happens all the time
triangulation of multiple specialities
they clicked and somebody said, that might be something or other
patients cross fertilise different communities of practice
House series â interesting show because you have doctor who can puzzle things because he is a cross-specialist
can turn every doctor into a House guy
from J&J perspective: 1. look for areas of business where customer data and shared access to it would make a difference to the business itself and its operations, product development, distribution etc 2. look for areas of business where there already is access to data and how it can be enhanced by VRM, what business benefits that would have 3. look for communities related to 1. & 2. 4. familiarise yourself with new approaches and the net dynamics - open source, long tail, attention economy, identity, VRM etc 5.
Doctors might hate the idea â response might be there is too much info to patients, self-diagnoses
you can only help by informing them
Security requirements for VRM include the standard model
1) authentication: the ability to establish an 'identity' for each user of the system 2) authoristion: the ability to establish capabilities/privileges which are strongly bound to an each identity, eg: ability to read, write, or delete blobs... 3) integrity: the ability to protect blobs against modification/forgery/amendments, eg: by use of digital signatures bound to identities 4) secrecy/privacy: the implementation of access controls of data at rest or in motion, so that blobs cannot be read by those without authorisation
Two architectures for implementation of the security model were suggested:
a 'fortress' model, where those who desire access to data must successfully authenticate themselves to the data repository before retrieval. a 'broadcast' model, where data is broadcast, unicast or published but under encryption, where only those with authorisation possess keys for access
distributed just coz it's sexy? It's a necessary because it's more resilient
Alec: basically the discussion was about: should we consider making a VRM pilot and simplify our lives by making the assumption that the database would be wholly centralised; the answer to that was an emphatic NO; the reason being that working from a perspective of "the data is centralised in a fortress" will lead to thinking that will never be able to accommodate a distributed architecture; whereas there is nothing to prevent an architecture which is capable of distribution in a wholly or partly centralised matter, as a convenience. In short: the web-browser would never have been invented had someone elected to ignore the distributed nature of the Web; instead, they would have merely yet again reinvented the file-browser. So: DESIGN IT DISTRIBUTED, TEST IT DISTRIBUTED, BUT IMPLEMENT IT HOWEVER YOU CHOOSE.
personal data stores â data objects
design it around one big machine everyone will talk to â you are predetermining design
if you design breakable because then it doesn't matter because there are enough distributed machines, VRM lifestyle â approach â embracing distributed model will save a lot of pain in the long run
client- server? Duncan's reminder
Virgin not trusted because private company, social enterprises trusted more
trusted storage â telcos, banks, private, public?
where do you stick the data?
credit boom started â CRM was started by financial industry handling a number of customers due to increased demand
flacking â helping to sell something via third party â use and abuse of trust
who would you trust as a company to held your keys?