Re: [projectvrm] Can I tell you a story ....

[Doc Searls < >]

That sounds cool. Let's put it together at IIW.

Doc

> On Mar 16, 2015, at 2:32 PM, Markus Sabadello 
> <
 >
>  wrote:
> 
> So if you're just talking about the vocabulary and not about protocols
> (which is a very smart separation I think), then this should indeed be
> not so difficult.
> 
> I don't think I have ever seen any standardized way of expressing a
> relationship between customer and supplier.
> 
> I agree Good Relations probably has some parts of this, e.g. the "Offer"
> class which I am sure you know:
> http://schema.org/Offer
> 
> In the W3C Social WG I found the following, which could be relevant:
> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Offering_asparagus
> 
> But I understand those are just parts of what you're looking for.
> 
> Why not just get something started on a wiki page or Github repo?
> Now that I think of it this could be really exciting.
> 
> What if Customer Commons published a simple OWL ontology (and/or XDI
> dictionary) that defined a SINGLE relation: X hasSupplier Y
> This could then be expanded/refined of course, but even defining that
> one thing could be a HUGE (symbolic) first step, no? :)
> 
> Markus
> 
> On 03/17/2015 02:02 AM, Iain Henderson wrote:
>> Hi Markus, yes I well remember all those conversations with Paul and 
>> personal data store popping out as an area of general consensus.
>> 
>> To your point about standards, I think we perhaps do need to be more 
>> specific. What i’m referring to is a data standard that defines the data 
>> required around me and my suppliers. The technical means of moving that 
>> data around, managing identity and access control and the like are related 
>> but not what i’m describing. Higgins came relatively close on some aspects 
>> of that’ albeit with some assumptions about ontologies. I’m fairly sure 
>> there is nothing out there as a public standard in that space. There are 
>> some in adjacent spaces or sub-sets, such as postal address standards, or 
>> Good Relations on Products/ Services; anything beyond that then let’s air 
>> them on the list for discussion.
>> 
>> Cheers
>> 
>> Iain
>> 
>> 
>> 
>> 
>> 
>>> On 16 Mar 2015, at 15:00, Markus Sabadello 
>>> <
 >
>>>  wrote:
>>> 
>>> For me, the most interesting aspect of Higgins was that it started by
>>> defining an abstract data model with a single and very light API
>>> ("IdAS") and several plugins that allowed you to access (parts of) your
>>> personal data from all over the Internet.
>>> 
>>> It took a long time before Higgins itself provided a "perferred" way of
>>> storing personal data in a place you control, which was eventually
>>> called "personal data store".
>>> 
>>> In other words, Higgins was first concerned with interoperability with
>>> external services, and only second with storing personal data "in 
>>> Higgins".
>>> 
>>> Today, it mostly seems the other way round. People develop personal
>>> clouds, and afterwards (maybe) ask the question how to interoperate with
>>> others.
>>> 
>>> Before starting yet another standard, maybe a useful project would be to
>>> map out the standards that are currently out there and potentially
>>> relevant for personal clouds.
>>> What functions they aim to fulfill, how they relate to each other, etc.
>>> Such work could be done by Customer Commons, or PDEC would also be an
>>> obvious place.
>>> Anyone interested?
>>> 
>>> Markus
>>> 
>>> On 03/16/2015 04:25 PM, Iain Henderson wrote:
>>>> Hi Julian,
>>>> 
>>>> I understand the point you are making on the data standards/ ontology 
>>>> issue, and it makes sense from an individual organisational stand point. 
>>>> The problem is, multiple other entities are pursuing the same approach, 
>>>> dating way back to at least the Higgins project which was (is) open and 
>>>> used best of breed available wherever possible.
>>>> 
>>>> With my CRM Manager hat on, this makes it almost impossible to engage 
>>>> with a VRM solution/ bring my customer base to the party prior to it 
>>>> gaining large scale. The lack of an open standard schema/ ontology 
>>>> around personal clouds is, in my view, pretty much the only thing now 
>>>> holding back the personal cloud model from large scale adoption. XDI 
>>>> promises to help in this area, but in practice is some time away from 
>>>> being able to meet that need globally and at scale; sufficiently far 
>>>> away that we can’t wait for it.
>>>> 
>>>> The upsides to opening up and working on a cross-industry collaboration 
>>>> would likely far outweigh the downsides; and if there is a mind to 
>>>> collaborate, the actual task itself is not that difficult. Without it we 
>>>> just create more silos on the VRM side as well as the CRM side.
>>>> 
>>>> Doc - we could host such a standard at Customer Commons?
>>>> 
>>>> Cheers
>>>> 
>>>> Iain
>>>> 
>>>> 
>>>>> On 14 Mar 2015, at 11:41, Julian Ranger 
>>>>> <
 >
>>>>>  wrote:
>>>>> 
>>>>> Ah all these marriage proposals – makes me wish I was back in my 20s 
>>>>> and 30s!
>>>>> 
>>>>> The standards issue you raise is a good one and could be used to start 
>>>>> a long train of thought.  I should firstly state that I am totally in 
>>>>> favour of standards before I bring my BUT into play.  I spent 19 years 
>>>>> building a business in the military internet arena (which I eventually 
>>>>> sold to Lockheed Martin) that was based predominately around standards; 
>>>>> however, to achieve interoperability across systems, all of which had 
>>>>> implemented standards but different ones for different purposes and to 
>>>>> different levels of completeness and competence, it was necessary to 
>>>>> create a new process (iSMART) that borrowed from these standards, 
>>>>> incorporated them, but ultimately was itself a new standard that had to 
>>>>> be implemented first by some, then by more, before it ultimately became 
>>>>> the gold standard.
>>>>> 
>>>>> What we are doing in digi.me is analogous to the approach we took for 
>>>>> the military problem.  We are incorporating and using data standards in 
>>>>> our own normalised ontology, but that ontology is itself new.  We will 
>>>>> publish that ontology when we open the Permission Access API and hope 
>>>>> through its use, and because we are not perverse and have based it on 
>>>>> strong standards (and pseudo standards by which I mean ontologies which 
>>>>> are commonly used but are not necessarily standards in themselves), 
>>>>> that it will become a de facto standard – and we wouldn’t stand in the 
>>>>> way of it being made an open standard.  Why are we doing this and not 
>>>>> using a standard today? – because no standard today covers everything, 
>>>>> or even most of, what we need to cover, so we have to do something new.
>>>>> 
>>>>> Carrying on the marriage theme “something old, something new, something 
>>>>> borrowed, something blue” our answer  incorporates the old and the 
>>>>> borrowed with the new – not sure we’ve got blue covered though yet!
>>>>> 
>>>>> I am not in a position yet to release our ontology and normalisation 
>>>>> processes because of commercial reasons.  Not only will they make it 
>>>>> easier for businesses to use digi.me data, but the process also makes 
>>>>> our software easier to implement and scalable and that is a competitive 
>>>>> advantage that we cannot forgo until we are close to releasing the open 
>>>>> API.  That said I default to as much openness about what we’re doing, 
>>>>> why and with whom as I can and I am therefore happy to answer further 
>>>>> questions and discuss the principles, etc but please excuse me if I 
>>>>> have to stay silent on some aspects.
>>>>> 
>>>>> Cheers, Jules
>>>>> 
>>>>> 
>>>>> 
>>>>> From: 
>>>>> 
 
>>>>>  
>>>>> [mailto:
 ]
>>>>>  On Behalf Of Adrian Gropper
>>>>> Sent: 14 March 2015 02:12
>>>>> To: Julian Ranger
>>>>> Cc: ProjectVRM list; T.Rob
>>>>> Subject: Re: [projectvrm] Can I tell you a story ....
>>>>> 
>>>>> I watched the video and share T.Rob's love. Maybe digi.me will move to 
>>>>> Utah so we can all marry you. 
>>>>> 
>>>>> The logic of what you're doing is impeccable but it raises the question 
>>>>> of standards. An authorization service would need to be substitutable 
>>>>> in order to compete with the likes of Apple at doing the same job by 
>>>>> extending HealthKit and ResearchKit where they say: "Apple will not see 
>>>>> your data." (But Apple controls the apps.) The UMA standard is meant to 
>>>>> address some of what you're doing, for example. 
>>>>> 
>>>>> What is the role of standards in your service and your business model 
>>>>> as post office?
>>>>> 
>>>>> Adrian
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Mar 13, 2015 at 7:52 PM, Julian Ranger 
>>>>> <
 >
>>>>>  wrote:
>>>>> T.Rob,
>>>>> 
>>>>> Thank you for your kind words – all offers of marriage gratefully 
>>>>> considered (but unfortunately my wife has final say!).  More seriously 
>>>>> we will of course work with anyone who wants to further the progress of 
>>>>> personal data.
>>>>> 
>>>>> Answering your questions as follows:
>>>>> Q1:  You mention the ability to choose a cloud storage provider but do 
>>>>> not mention that the data is encrypted.  After the discussion of how we 
>>>>> would not trust any one vendor with all that data, I assume that it is 
>>>>> encrypted locally before transmission to the cloud storage provider, 
>>>>> yes?
>>>>> 
>>>>> A1:  Yes the data is encrypted.
>>>>> 
>>>>> Q2:  The video mentions Amazon, FitBit and others but the Pricing page 
>>>>> lists only "social network accounts."  Are the vendor accounts free, 
>>>>> counted as social media accounts, or are they not there yet?  Have you 
>>>>> considered collaborating (or merging) with FileThis who already fetch  
>>>>> tons of utility bills and bank account statements?
>>>>> 
>>>>> A2: As of today we have implemented only social media accounts (which 
>>>>> have massive amounts of data I might add) – because they are the most 
>>>>> evocative.  As we progress through 2015 and into 2016 we will add the 
>>>>> other accounts we mention.  For example we are working on getting step 
>>>>> data and Transport for London data for a particular application we are 
>>>>> working with a health provider in London on – over 2,000 people in 
>>>>> London die each year because they do not walk enough!
>>>>> 
>>>>> Q3:  Is there an open API to develop our own apps against the data?  
>>>>> One of the biggest issues with Internet of Things is that proprietary 
>>>>> devices interface only with whatever other devices the vendor thinks 
>>>>> have a possibility of strong ROI for the development costs.  As cool as 
>>>>> Digi.me sounds, the idea of waiting endlessly for the company to clear 
>>>>> off the high priority interfaces and get to the niche integrations is a 
>>>>> total turn-off.  (For those who haven't realized it yet, the long tail 
>>>>> *is* the tail.  If your Internet biz doesn't scale to handle niche 
>>>>> cases, it isn't an Internet biz, or if it is it won't be for long.)
>>>>> 
>>>>> A3: You won’t be surprised to know that we are constrained by funding 
>>>>> as to what we can do when.  Clearly, distribution is key – no one will 
>>>>> want to access data (with user Permission of course!) if there aren’t 
>>>>> many users.  Cost of acquisition with a direct acquisition model gets 
>>>>> expensive quickly, so we have a partnership model as our main user 
>>>>> acquisition channel initially.  Therefore in 2015 Permission Access is 
>>>>> being worked on for our main partners only – those who can 
>>>>> strategically get us lots of users (Telcos, FMSCG, banks, insurers – 
>>>>> all whilst following our strict Permission Access principles) and who 
>>>>> can gives us some money as well.  We expect to have an anyone can 
>>>>> access your data API (again with Permission of course) by mid 2016 at 
>>>>> the latest.  If anyone wants earlier access then just email me and 
>>>>> we’ll see what we can do – we’re moving as fast as we can.
>>>>> 
>>>>> Q4:  Can I route my email receipts through Digi.me?  For example my 
>>>>> bank, department store, sporting goods store, and most online stores 
>>>>> will send me an email receipt.  These are almost all text so they can 
>>>>> be dropped as-is into a DB and become instantly searchable.
>>>>> 
>>>>> A4:Not on the plan for 2015 nor 2016.  Others may do this and move the 
>>>>> data when we have the general purpose API available in 2016, but for 
>>>>> now we are concentrating on direct access to data via APIs only.  (I’d 
>>>>> love to buy one of the companies that does a lot of this already, but 
>>>>> strategically it’s not the most important think we can do – I think.)
>>>>> 
>>>>> Q5:  Is the pricing structure scalable?  At some point do you stop 
>>>>> counting accounts and just go by bandwidth?  Because I hit 20 social 
>>>>> media accounts before I even start counting the vendor accounts and I 
>>>>> probably have way more than 20 of those.  Thinking of the Long Tail 
>>>>> again, I'm not worried that Digi.me will capture my Duke Power 
>>>>> interactions, it's the appliance repair guy or the tree surgeon I used 
>>>>> a couple of years ago that I *really* need help remembering.  If 
>>>>> Digi.me believes per-account pricing is the way to go, there's a 
>>>>> natural incentive to *not* load up data from occasional vendors, which 
>>>>> would by design omit large swathes of useful info, thereby crippling 
>>>>> the app to some extent.  I'm the CEO of my family and I want an 
>>>>> enterprise license, dammit!
>>>>> 
>>>>> A5:  Taking the pricing answer from my email to JP:
>>>>> 
>>>>> “The video doesn’t really explain our charging model, so as you mention 
>>>>> the “The Free is the Lie” syndrome I’ll address it.  Today we DO charge 
>>>>> for the basic software – at a low $7 a year for basic premium features; 
>>>>> however, in time the software functionality of digi.me will be free.  
>>>>> Our main revenue will be from postal charges – when you Permission 
>>>>> Access to some element(s) of your data and your digi.me app ”posts” 
>>>>> that data to another app/web page/etc then a postal fee is charged by 
>>>>> digi.me to the receiving entity.  This postal fee will only be 
>>>>> cents/tens of cents each time (or for a regular “subscription”) but 
>>>>> will add to $20 or so per user per year (roughly)and when you consider 
>>>>> we don’t hold data, process it or have bandwidth then that makes us 
>>>>> profitable without the need to take commission, sell your data or 
>>>>> anything else.  Our mission is to be dreadfully boring – be your 
>>>>> Librarian and Postman and nothing else”
>>>>> So you won’t in the medium term pay per channel at all – only when you 
>>>>> Permission Access to your data, and then you won’t pay, but the 
>>>>> receiver will.  Yes, we charge now, but that is because until our 
>>>>> Permission Access API is up and running we have to make some money – 
>>>>> and we have partners who do get many customers for us by selling our 
>>>>> software.  For example FNAC in France sell our software as part of a 
>>>>> security pack.
>>>>> I hope that gives you further detail and responds to your questions 
>>>>> adequately, but do fire in my thoughts questions, comments.
>>>>> 
>>>>> Cheers Jules
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ---------- Forwarded message ----------
>>>>> From: T.Rob 
>>>>> <
 >
>>>>> Date: Fri, Mar 13, 2015 at 1:51 PM
>>>>> Subject: RE: [projectvrm] Can I tell you a story ....
>>>>> To: Julian Ranger 
>>>>> <
 >,
>>>>>  ProjectVRM list 
>>>>> <
 >
>>>>> 
>>>>> I'm in love!  Can I marry Digi.me?
>>>>> 
>>>>> Seriously though, I do have a couple of questions from the video.
>>>>> 
>>>>> ·       You mention the ability to choose a cloud storage provider but 
>>>>> do not mention that the data is encrypted.  After the discussion of how 
>>>>> we would not trust any one vendor with all that data, I assume that it 
>>>>> is encrypted locally before transmission to the cloud storage provider, 
>>>>> yes?
>>>>> 
>>>>> ·       The video mentions Amazon, FitBit and others but the Pricing 
>>>>> page lists only "social network accounts."  Are the vendor accounts 
>>>>> free, counted as social media accounts, or are they not there yet?  
>>>>> Have you considered collaborating (or merging) with FileThis who 
>>>>> already fetch  tons of utility bills and bank account statements?
>>>>> 
>>>>> ·       Is there an open API to develop our own apps against the data?  
>>>>> One of the biggest issues with Internet of Things is that proprietary 
>>>>> devices interface only with whatever other devices the vendor thinks 
>>>>> have a possibility of strong ROI for the development costs.  As cool as 
>>>>> Digi.me sounds, the idea of waiting endlessly for the company to clear 
>>>>> off the high priority interfaces and get to the niche integrations is a 
>>>>> total turn-off.  (For those who haven't realized it yet, the long tail 
>>>>> *is* the tail.  If your Internet biz doesn't scale to handle niche 
>>>>> cases, it isn't an Internet biz, or if it is it won't be for long.)
>>>>> 
>>>>> ·       Can I route my email receipts through Digi.me?  For example my 
>>>>> bank, department store, sporting goods store, and most online stores 
>>>>> will send me an email receipt.  These are almost all text so they can 
>>>>> be dropped as-is into a DB and become instantly searchable.
>>>>> 
>>>>> ·       Is the pricing structure scalable?  At some point do you stop 
>>>>> counting accounts and just go by bandwidth?  Because I hit 20 social 
>>>>> media accounts before I even start counting the vendor accounts and I 
>>>>> probably have way more than 20 of those.  Thinking of the Long Tail 
>>>>> again, I'm not worried that Digi.me will capture my Duke Power 
>>>>> interactions, it's the appliance repair guy or the tree surgeon I used 
>>>>> a couple of years ago that I *really* need help remembering.  If 
>>>>> Digi.me believes per-account pricing is the way to go, there's a 
>>>>> natural incentive to *not* load up data from occasional vendors, which 
>>>>> would by design omit large swathes of useful info, thereby crippling 
>>>>> the app to some extent.  I'm the CEO of my family and I want an 
>>>>> enterprise license, dammit!  J
>>>>> 
>>>>> 
>>>>> I'll go sign up later.  Tonight I'm in charge of dinner and, as I 
>>>>> posted earlier to Facebook, my soup has that "new crock pot smell."  I 
>>>>> think I'll have to run to the store for something to grill real fast. 
>>>>> 
>>>>> Kind regards,
>>>>> -- T.Rob
>>>>> 
>>>>> I have availability! For a good time (with IBM MQ) call:
>>>>> T.Robert Wyatt, Managing partner
>>>>> IoPT Consulting, LLC
>>>>> +1 704-443-TROB (8762) Voice/Text
>>>>> +44 (0) 8714 089 546  Voice
>>>>> https://ioptconsulting.com
>>>>> https://twitter.com/tdotrob
>>>>> 
>>>>> From: Julian Ranger 
>>>>> [mailto:
 
>>>>> ]
>>>>> Sent: Friday, March 13, 2015 12:34 PM
>>>>> To: ProjectVRM list
>>>>> Subject: [projectvrm] Can I tell you a story ....
>>>>> 
>>>>> …. using a pack of cards?
>>>>> 
>>>>> Time for me to tell you all what we’re really up to at digi.me – please 
>>>>> look at http://digi.me/video
>>>>> 
>>>>> We’re over 270K licences out there now, growing fast, and expect some 
>>>>> major partnerships we have in final stages to take us beyond first 
>>>>> million this year – moving.  The personal cloud and iOS mobile versions 
>>>>> mentioned in the video all get released this month; the PC/Mac versions 
>>>>> have been around for a long time and are now at a true V7. Permission 
>>>>> Access will be open to select partners this year and to the world from 
>>>>> mid-2016.
>>>>> 
>>>>> Comments, questions, thoughts all very welcome.
>>>>> 
>>>>> Cheers, Jules
>>>>> 
>>>>> Julian Ranger
>>>>> Founder & Chairman, digi.me (formerly SocialSafe)
>>>>> 
>>>>> 
 
>>>>> 
>>>>> http://digi.me – It’s your life
>>>>> 
>>>>> Mobile: +44 7802 207470
>>>>> 
>>>>> @rangerj
>>>>> uk.linkedin.com/in/julianranger/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Adrian Gropper MD
>>>>> Ensure Health Information Privacy. Support Patient Privacy Rights.
>>>>> http://patientprivacyrights.org/donate-2/
>>>> This email and any attachment contains information which is private and 
>>>> confidential and is intended for the addressee only. If you are not an 
>>>> addressee, you are not authorised to read, copy or use the e-mail or any 
>>>> attachment. If you have received this e-mail in error, please notify the 
>>>> sender by return e-mail and then destroy it.
>>>> 
>>> 
>> This email and any attachment contains information which is private and 
>> confidential and is intended for the addressee only. If you are not an 
>> addressee, you are not authorised to read, copy or use the e-mail or any 
>> attachment. If you have received this e-mail in error, please notify the 
>> sender by return e-mail and then destroy it.
>> 
> 
>