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

[Iain Henderson < >]

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.