Re: [projectvrm] All My Purchases App -- a Moo Moment.

[Iain Henderson < >]

Yes, there are quite a few that do so - just none as yet that send to a 
personal data service (because there aren't any of those available at 
sufficient scale as yet).

 And yes, all of those supply side benefits emerge in the PDS-enabled mode 
(steps 5 to 11 in the Customer - Supplier Engagement Framework.....).

Iain


On 27 May 2011, at 22:29, Joe Andrieu wrote:

> It's also worth noting that Wells Fargo now offers several forms of ditial 
> receipts for ATM transactions, including sending it to your email of record.
> 
> I think the real trick is to be able to streamline the secondary uses of 
> receipts for the authorizing vendor, e.g., returns, rebates, warranties, 
> recalls and various customer service issues. It's all fine that a vendor 
> pushes out data in a friendly format, but it will take the game to a whole 
> new level when they accept that data back into their system as a proof of 
> purchase.
> 
> -j
> Joe Andrieu
> 
> 
 
> 
> +1 (805) 705-8651
> 
> 
> On 5/27/2011 2:24 PM, Iain Henderson wrote:
>> Sure, there are issues to be addressed, but none un-resolvable over time.
>> 
>> I'm a believer in going after the easy bits first, and using the momentum 
>> that generates to build out. For example, in UK a huge proportion of £'s 
>> spent on groceries is with one company (Tesco), who already digitise 
>> receipts for the vast majority of their customers (who have Clubcards). I 
>> should have an option to opt out of paper receipts at the till, have that 
>> preference tagged in my Clubcard account, and have the receipts and data 
>> at item level fired off into my personal data service.
>> 
>> There's nothing difficult about that. Come to think of it, we'll raise 
>> that with them, and the others in the UK.gov mydata project.
>> 
>> Iain
>> 
>> 
>> 
>> On 27 May 2011, at 17:35, Mark Lizar wrote:
>> 
>>   
>> 
>>> Very Good Points Charles,
>>> 
>>> Iain, Luk do your backends cover some/all of these issues?
>>> 
>>> Alternatively, a work around to alot of these problems can be achieved 
>>> with an install program that enables the vendor to map the fields of the 
>>> receipts to the Online Data Store upon installing the vendor side 
>>> application.
>>> 
>>> There are other tricks as well.
>>> 
>>> MOOOOOO!
>>> 
>>> 
>>> On 27 May 2011, at 15:40, Charles Andres wrote:
>>> 
>>>     
>>> 
>>>> A few of the obstacles -- and the ultimate standard -- English 
>>>> language*, Arabic numbers , unambiguous context - a place where lawyers 
>>>> can agree that the receipt is intelligible to both parties.
>>>> *(Mandarin is perhaps less efficient as context requires tonal parsing 
>>>> and much larger character sets)
>>>> 
>>>> Receipt issuers have little interest in conforming to a data interchange 
>>>> standard.
>>>> The receipt is considered a record of a private contract between two 
>>>> parties; not an information source to be used for other purposes.
>>>> 
>>>> Further, the information on digital receipts is wildly variable. The 
>>>> only  common datum are the date (with finite format variances)  and the 
>>>> total amount charged, lumping together individual items, tax, etc which 
>>>> appear differently from every distributor/state-province. There are 
>>>> services like shoeboxed.com that can perform this elementary level of 
>>>> parsing even for paper receipts. To go to the next level,  parsing needs 
>>>> to be done on a case by case basis. You could create rules for Amazon, 
>>>> Apple, EBay, etc. and maintain updates as their formats change from time 
>>>> to time but doing this needs to be pooled for efficiency -- 
>>>> infrastructure services could do this, but they need to sell this to 
>>>> someone.
>>>> 
>>>> At least the digital receipt can be converted to ASCII if it is not 
>>>> already in that fundamental form. Paper receipts have the additional 
>>>> character to ASCII parsing problem. Then you need to interpret the 
>>>> meaning of the ASCII strings and normalize it into defined data fields 
>>>> that can be used for other purposes. Data cleansing may require manual 
>>>> intervention.
>>>> 
>>>> Suppose a standard is proposed. It then needs to be adopted by a 
>>>> significant number of retailers to be considered a useful standard for 
>>>> any data gathering system.  This is difficult to make happen without  
>>>> either a federal mandate or a significant business advantage that 
>>>> continues after the leveling effect of universal adoption.  Ahead of 
>>>> that, the advantage has to be sold to each distributor so they budget 
>>>> the funds to adopt and support the standard.
>>>> 
>>>> While we wait, parsing algorithms get smarter, but this is a tough 
>>>> problem to solve.
>>>> 
>>>> So there you have it -- the cowboys  (sellers) herding cattle (buyers) 
>>>> are not interested in the divinity of bovines (re: Craig Burton) or cow 
>>>> equality. They like the system the way it is.  But as the herd acquires 
>>>> smarter affordable gadgets, they will cause defacto open standards to 
>>>> emerge that can free the data to be used in multiple ways to benefit the 
>>>> cows (buyers).
>>>> 
>>>> Viva la  Vaca!
>>>> - The Mad Cow
>>>> 
>>>> P.S. As dairy farmers well know, the fence holding the cows in is puny, 
>>>> but the herd respects it most of the time (zap). Now and then, one of 
>>>> the herd tramples down the fence and the cows escape for a while, 
>>>> usually in the spring.  The cost-benefit ratio of flimsy fence / number 
>>>> of break-outs is within acceptable bounds. Warning: more break-outs 
>>>> inevitably leads to stronger more expensive fences and higher milk 
>>>> prices. YMMV ;-)
>>>> 
>>>> On May 27, 2011, at 3:15 AM, Iain Henderson wrote:
>>>> 
>>>>       
>>>> 
>>>>> Yes, and let's not forget the offline world. A colleague of mine 
>>>>> covered digitising receipts in her MSc thesis and came up with 
>>>>> fascinating numbers, like the miles of paper that supermarkets churn 
>>>>> out each week that go straight in the bin. Much of this is just a 
>>>>> legacy way of doing things crying out for a standardised fix.
>>>>> 
>>>>> Count me in for this project work if we get it going.
>>>>> 
>>>>> Iain
>>>>> 
>>>>> On 27 May 2011, at 00:58, Doc Searls 
>>>>> <
 >
>>>>>  wrote:
>>>>> 
>>>>>         
>>>>> 
>>>>>> On May 26, 2011, at 5:32 PM, Brian Behlendorf wrote:
>>>>>> 
>>>>>>           
>>>>>> 
>>>>>>> Why not a standard for emailed purchase receipts?
>>>>>>>             
>>>>>>> 
>>>>>> Great idea!
>>>>>> 
>>>>>> Could it be there's already one we don't know?
>>>>>> 
>>>>>>           
>>>>>> 
>>>>>>> For no good reason, today I get email messages confirming purchases 
>>>>>>> in all sorts of different formats.  One could pretty easily imagine a 
>>>>>>> standard that preserved the ability to view the message in an 
>>>>>>> HTML-ish mail client, but which also embedded enough metadata 
>>>>>>> (microformats-style, or as a small attachment a la VCF) to allow a 
>>>>>>> message to be fed to a client-side application that did interesting 
>>>>>>> things with the data - like helped me keep track of purchasing 
>>>>>>> habits, a personal-property inventory system for insurance purposes, 
>>>>>>> a warranty tracking system so that when X breaks I know quickly what 
>>>>>>> number to call and if it's still in service, etc.  It could also thus 
>>>>>>> feed a VRM system entirely client side, or on a personal cloud of 
>>>>>>> one's choice, in a manner much more semantically meaningful than free 
>>>>>>> text association.
>>>>>>> 
>>>>>>> Then, let a thousand All My Purchases apps bloom.
>>>>>>> 
>>>>>>> Brian
>>>>>>>             
>>>>>>> 
>>>>>> Yay! Let's do it.
>>>>>> 
>>>>>> Doc
>>>>>> 
>>>>>> 
>>>>>>           
>>>>>> 
>> 
>> 
>> e-mail: 
>> 
 
>> 
>> blog: 
>> www.iainhenderson.info
>> 
>> twitter: @iainh1
>> 
>> 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.
>> 
>> 
>> 
>> 
>>   
>> 


e-mail: 

 
blog: www.iainhenderson.info
twitter: @iainh1

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.