All posts in the topic Open Data - Barcodes (Short link)
Summary
- There are 53 posts — by 17 authors — in this topic.
- Latest post made by hads at May 14 17:24 NZST
Here's another type of data that needs to be opened up, http://www.gs1.org/gdsn/gpc Using Pic2shop I can read barcodes with my iPhone. Unfortunately there doesn't seem to be a NZ Product database. It works for products made in the US. Having accurate barcodes would open up a whole new potential for value add apps. Sent from my iPhone
On 15 April 2010 23:32, Mike Pearson <email obscured>> wrote: > Here's another type of data that needs to be opened up, > http://www.gs1.org/gdsn/gpc > > Using Pic2shop I can read barcodes with my iPhone. Unfortunately there > doesn't seem to be a NZ Product database. It works for products made > in the US. > > Well, there will be a database.. but not it's unlikely to be freely available. http://www.gs1nz.org/ is GS1's New Zealand affiliate, based in Wellington. It would be interesting to see what would happen if there was an OpenStreetMaps equivalent for bar codes. E.g. consumers input the bar code, price, where sold & date. Quite soon you would have a very rich source of economic data to be able to track inflation in various sectors extremely accurately. I don't know how many goods I would register though... at least with OpenStreetMaps you can see the world grow.
I for one have been mulling this for some time.
Bar code reader software has been an option for many cell phones for months
(years?)
Bar codes could provide a link to ingredients and to source
Bar codes and associated data are possibly an excellent opportunity for
crowd sourcing
If I could be alerted to peanuts in food then I wouldn't need to get my
glasses off and peer at the small cryptic print
There are many other services that could be created if the barcodes worked
On Fri, Apr 16, 2010 at 8:48 AM, Tim McNamara
On 16/04/2010, at 9:29 AM, Jim McLeod wrote:
> Bar code reader software has been an option for many cell phones for
> months
> (years?)
Only a few years, roughly since the time of the iPhone. I remember
briefing Jeff Bezos about mobile phones and barcodes, circa 2005, and
at the time the state of the art cameras were still a little short of
the resolution needed to be able to register barcodes.
On 16 April 2010 09:29, Jim McLeod <email obscured>> wrote:
> If I could be alerted to peanuts in food then I wouldn't need to get my
> glasses off and peer at the small cryptic print
>
There's something that's really valuable. For me personally, it would be
great to be able to scan a barcode & have something quickly pop up
"Vegetarian", "Contains additives that are potentially sourced from animal
by-products", etc etc.
In a similar vein, it would be handy to have the app identify the E numbers
& link to contents from Wikipedia about the chemical.
Hi, I have spoken to Gary Hartley at http://www.gs1nz.org. ABOUT GS1 GS1 is a global organisation, run from Brussels. It has a NZ branch. GS1's mission and values are compatible, http://www.gs1nz.org/VisionMission.aspx. GS1 BARCODES GS1 allocates barcode prefixes to companies, and allocate a range of SKU numbers. Most NZ products will have a GS1 barcode. For example, 9415077. Using http://gepir.gs1.org/v31/xx/gtin.aspx?Lang=en-US, you can query Trade Item Ownership, and see this belongs to Foodstuff. A company allocates its own SKU number to a product. GS1 has no visibility of this, unless the company chooses to upload the relationship. Using http://gepir.gs1.org/v31/xx/gtin.aspx?Lang=en-US, you can query Trade Item Info, and see no information has been loaded about this item. If the information was loaded, then you'd know 9415077-02882-5, 9415077=Foodstuffs, 02882=250 Facial Tissues 2 Ply White, 5=check digit modulus 10. GS1 DATA GS1 have a service called GS1Net. It allows suppliers to upload information into a global product registry. It was developed 3-4 years ago (pre-smartphones / open data). It currently has no public API. It does have a subscription based API. There isn't an exact match for what app developers would do, but it looks like it might cost $700/per quarter. http://www.gs1nz.org/documents/GS1netFeesTermsConditions.aspx My 2c, I think the FeesTermsConditions probably need a review in light of new technologies/opportunities for apps. MOBILE COMMERCE GS1 at a global level see mobile commerce as an important strategic work area. GS1 sees its role as providing access to AUTHENTICATED sources of product information. Authentication is important, as unreliable information can cause disruption. They are currently looking at adding extended packaging information - does it contain peanuts (allergy); is it halal? is it organic certified? GS1 (NZ) understands the growing importance of mobile commerce and adding value to business/consumer. Gary is looking at organising a mobile commerce day for retailers/suppliers on 15th June in Auckland; probably with some international speakers. My impression was that it would be focused on supply chain efficiencies; I have suggested they could also do a barcamp or similar in Wellington, and we could get more of a developer/consumer focus. FOLLOWUP I will be having a followup meeting on 27th April with Gary and will let you know. Regards Mike
My experience has been that you needed a special case with a closeup
lens for the original iPhone, so it was a hassle.
The iPhone 3Gs focuses closeup without any effort. I've tried a couple
of bar coding apps and the developers seem to be getting smarter with
the image processing, because it gets faster with every update.
pic2shop recognises a barcode in less than a second now, with good light.
Barcoding has a lot of potential, not just for product information.
For example, there's a NZ Courierpost app, and I've suggested to the
developer that he use barcode recognition, rather than me typing in a 13
digit barcode for each parcel I send.
Regards mike
Authenticated means supplied by the supplier? That is interesting as the supplier has a vested interest in showing you only 'good' data. On a related note I'm not sure if everyone on the list knows about Good Guide - http://www.goodguide.com This market will be HUGE in the coming years. Tracking the package of meat back to the source cow will make things interesting and a lot better than the fake baacodes that Icebreaker uses.
> > *Authenticated means supplied by the supplier? That is interesting as the > supplier has a vested interest in showing you only 'good' data.* An opportunity for crowd sourcing - no? Both for original data and trustworthiness of the supplier. *Tracking the package of meat back to the source cow will make things > interesting and a lot better than the fake baacodes that Icebreaker uses.* Wasn't this what MAF's NAIT <http://www.nait.co.nz/nait_Updates.cfm?ar_id=1>was going to do?
On 16/04/2010, at 1:16 PM, Jim McLeod wrote:
> An opportunity for crowd sourcing - no?
> Both for original data and trustworthiness of the supplier.
I passed this thread onto my father, who's doing work in this area
around fish. Here's what he had to say:
On Fri, April 16, 2010 1:16 pm, Jim McLeod wrote: >> *Authenticated means supplied by the supplier? That is interesting as >> the >> supplier has a vested interest in showing you only 'good' data.* > > An opportunity for crowd sourcing - no? > Both for original data and trustworthiness of the supplier. > > *Tracking the package of meat back to the source cow will make things >> interesting and a lot better than the fake baacodes that Icebreaker >> uses.* > > Wasn't this what MAF's NAIT > <http://www.nait.co.nz/nait_Updates.cfm?ar_id=1>was going to do? I can see how NAIT could work for farm-to-farm tracking (and farm to slaughterhouse), but I was discussing this issue with sheep farmer friend and there are significant technical challenges to track the animal parts within the freezing works. Apparently a bin system has been trialled but that reduced processing performance by 50%, which makes processing uneconomic in what I understand to be an already lean sheep industry. I expect a realtime computer vision system might work, but it wouldn't be cheap...
On Fri, Apr 16, 2010 at 9:29 AM, Jim McLeod <email obscured>> wrote:
> I for one have been mulling this for some time.
> Bar code reader software has been an option for many cell phones for months
> (years?)
> Bar codes could provide a link to ingredients and to source
> Bar codes and associated data are possibly an excellent opportunity for
> crowd sourcing
> If I could be alerted to peanuts in food then I wouldn't need to get my
> glasses off and peer at the small cryptic print
> There are many other services that could be created if the barcodes worked
I'd be careful about doing that - recipes change without notice. I'd
hate for someone to actually use the barcode, instead of reading the
ingredients, and end up eating somethign they shouldn't.
I'd like to see it used to present info on the origins of the product
- more detail than the label can give us. The peanuts from china, the
salt from Marlborough, with a picture of the grassmere salt pile etc.
Take note that we are discussing factual and subjective attributes in the same thread. The barcode is assigned by the supplier. It is in the supplier's interest to accurately describe the SKU (stock keeping unit). This provides a way to globally identify a product with accuracy. The benefits are well known: http://www.gs1nz.org/GS1netBenefits.aspx. This is the information that GS1 means should be authoritative. You cannot dispute this information - it is factual. This is the information that I would argue should be open data. Then there are extended attributes that can be associated with products. These range from factual supplier provided attributes e.g. "allergy ingredients" to subjective consumer provided attributes e.g. "consumer goodness" or "after sales service". Some third party organisations hold a trusted position and their extended factual attributes are trusted. I did some thinking on this topic when I was involved in e-government. For instance, government tests/certifies electrical products for safety. This safety certification could be attached to the SKU barcode. Many extended attributes are subjective and we could argue about what is 'good' vs 'bad'. For instance, the NZ fishing industry would say many species are fished sustainably. Other groups would disagree, and they issue their own version of the state of NZ fish stocks, to influence consumers. I dont think the suppliers would have any interest in paying for a system that included 'bad' attributes. (Although they will be part of neutral forums if there is no bias e.g. Sustainable Business) The key point is that you need the product Global ID, so that app developers can link factual and subjective attributes about the same object.
Perhaps I joined too many dots when I heard the NAIT hype man say that
the elite Jap sushi customer could check the source of his snack.
Perhaps the bricks & mortar realities have caught up..
As for an allergies database someone has just sent this through to me..
The Manufactured Food Database (MFD) has been compiled by Nutrition
> Services, Auckland City Hospital from information voluntarily supplied by
> New Zealand food manufacturers.
NZFSA contracts the Manufactured Food Database to provide this information.
The MFD provides listings of manufactured foods available in New Zealand
> that are suitable for people with some common food allergies or
> intolerances. It includes egg, peanuts, wheat, gluten, soy, lactose.
All they need is to be able to link the barcodes to each product and you
GS1 Net has the option for manufacturers to notify a change to
subscribers. I'm not sure if its at a catalogue or individual SKU
level. Either way, it would make more sense for manufacturers to
publish to one point, rather than rely on third parties (ie a DHB to
contract to compile the information after the fact).
I'm not sure that GS1 will pick up these points, with the current focus
on supplier/purchaser. Bringing up these sort of consumer / developer
requirements while they are thinking about redeveloping GS1 Net, would
make for a potentially more valuable system for all parties.
You could quite easily with tuna. Just go to the Tokyo fish market and see the
individual fish being sold.
Sent from my iPad
Off-topic - Unless it's already been bought by Mitsubishi http://www.independent.co.uk/environment/nature/revealed-the-bid-to-corner-worlds-bluefin-tuna-market-1695479.html Sent from my employer's old XP box
My understanding with NAIT is that we're trying to catch up with the electronic tracking systems that have existed in competing countries for the last 10 years. Tracking has lots of benefits, from disease outbreak control, to consumer feedback. I did get involved with some of the initial design discussions. I raised a couple of points that hopefully they took on board: 1. If you are trying to catch up to systems that have been in place for 10 years, and its going to take 5 years to implement a system, then you need to take a big leap forward in your design. Otherwise at the time you implement your copycat system, your competitors will probably be announcing the new and improved Mark 2 system. 2. Tracking is only 1 part of the value chain. For a NZ competitive advantage you have to pool ALL your information; farmer, trucker, freezing works, shipper, govt inspector, retailer, consumer, and let all the parties extract extra value. I'll try to find my presentation. Some of the characteristics of such a system, are that you probably need the data owned by a cooperative; otherwise as the dataset builds, it increases in value, and the holder sees the potential to charge more for it. Rod Drury alluded to something similar recently, but I dont think people really picked up on the significance. http://www.stuff.co.nz/business/3519667/1b-from-milking-the-cloud
On 16/04/2010, at 2:11 PM, Jim McLeod wrote:
>> The Manufactured Food Database (MFD) has been compiled by Nutrition
>> Services, Auckland City Hospital from information voluntarily
>> supplied by
>> New Zealand food manufacturers.
I've been contacted out of the blue by a very enthusiastic and
experienced worker in the food allergy world, who's dead keen to get a
mobile app built that will let you snap a picture of a barcode and
immediately learn whether the MFD says it's any good good or not.
They'd also like to have crowdsourced updates (or at least flags for
updates), because manufacturers change ingredients often and the MFD
is updated yearly. This thread proved VERY timely!
She's spoken to the MFD, who are keen to open their data. Many thanks
to Mike for researching the GS1 barcode system. I need to test the
GS1 lookup to see whether the manufacturers of supermarket-type
products have uploaded their information to GS1. Even if the GS1
database is a dud, the food allergy folks are up to crowdsourcing a
barcode database for the food products that they care about. I'll bet
we could even speak nicely to a supermarket chain and they'd help with
that mapping.
Some things I've already thought of, but which aren't problems:
- new products are released all the time
- only expensive mobile phones can capture barcodes (I told her
this, and she said that if you buy for someone with food allergies you
either stick to a very small food range that you know is good or you
read squillions of labels, and many people have the means and the
desire to save that time and improve their breadth of diet by buying a
smartphone)
- texting off a photo of a barcode to get a response: the round-trip
time might be prohibitive. The point is to save time, so the barcode-
scanning experience has to be no slower than the time it would take to
read the label.
At this stage, it looks like it's possible to meet her needs with just:
- back-end web database with simple API to keep track of barcodes,
products and MFDs, with flags for user-contributed data
- tools to manage interaction between the official MFD database
(merge in their changes, send them our updates, etc.)
- mobile phone app to scan barcode, look up product in database (add
product if not found), look up warnings, update warnings
Does that seem like an accurate assessment of the problem and a
reasonable sketch of a solution that'd handle it?
Really interesting thread! I've also interested in this area for a number of years. Interest was rekindled a little while back with a project called Barcode Wiki, which unfortunately does not seem to be active at the moment: http://www.sicamp.org/?page_id=21 I'd be very interested in hearing about any open data on products that people know about. Also who would we need to talk to about opening up this kind of data? Crowd sourcing could be a very effective way to build up good quality data sets, but could be useful to seed this with some existing data. It would be great to start adding barcode/product information databases to CKAN, tagged with 'barcode' or suchlike, e.g. http://ckan.net/tag/barcode http://ckan.net/package/barcodepedia Re: technology, we are currently working on versioning for data (e.g. data registries, bibliographic data, public spending data, etc) which could be useful for projects in this area. Nat: might you be interested in doing a brief post on the vision behind this for the Open Knowledge Foundation blog? All the best,
On 12/05/2010, at 2:51 AM, Jonathan Gray wrote:
> Nat: might you be interested in doing a brief post on the vision
> behind this for the Open Knowledge Foundation blog?
Let's build something first. I'd rather talk about things I can point
to than castles in the air ....
Hey ninjas, I asked:
> At this stage, it looks like it's possible to meet her needs with
> just:
> - back-end web database with simple API to keep track of barcodes,
> products and MFDs, with flags for user-contributed data
> - tools to manage interaction between the official MFD database
> (merge in their changes, send them our updates, etc.)
> - mobile phone app to scan barcode, look up product in database (add
> product if not found), look up warnings, update warnings
>
> Does that seem like an accurate assessment of the problem and a
> reasonable sketch of a solution that'd handle it?
And didn't get a single response. I'm happy to help her by myself,
but I'd love to have the benefit of others' experience and advice!
Sorry for taking a while to read this Nat.
On 7 May 2010 22:12, Nathan Torkington <email obscured>> wrote:
> On 16/04/2010, at 2:11 PM, Jim McLeod wrote:
> >> The Manufactured Food Database (MFD) has been compiled by Nutrition
> >> Services, Auckland City Hospital from information voluntarily
> >> supplied by
> >> New Zealand food manufacturers.
>
> I've been contacted out of the blue by a very enthusiastic and
> experienced worker in the food allergy world, who's dead keen to get a
> mobile app built that will let you snap a picture of a barcode and
> immediately learn whether the MFD says it's any good good or not.
> They'd also like to have crowdsourced updates (or at least flags for
> updates), because manufacturers change ingredients often and the MFD
> is updated yearly. This thread proved VERY timely!
>
> She's spoken to the MFD, who are keen to open their data. Many thanks
> to Mike for researching the GS1 barcode system. I need to test the
> GS1 lookup to see whether the manufacturers of supermarket-type
> products have uploaded their information to GS1.
On lingo, it's "Fast-moving consumer goods" or the FMCG sector.
> Even if the GS1 database is a dud, the food allergy folks are up to
> crowdsourcing a
> barcode database for the food products that they care about. I'll bet
> we could even speak nicely to a supermarket chain and they'd help with
> that mapping.
Interesting.
I wonder if it's practical to create a confidential system to match people
with medic alerts & bar codes. See below.
On 12/05/2010, at 11:43 AM, Tim McNamara wrote:
> Looks like a good analysis.
Thanks!
Yup, I expect to see personalisation in the apps. And news: "what new
products can I eat?", "what products just changed their ingredients
and thus I should avoid?".
On Fri, May 7, 2010 at 10:12 PM, Nathan Torkington <email obscured>> wrote: > > > At this stage, it looks like it's possible to meet her needs with just: > - back-end web database with simple API to keep track of barcodes, > products and MFDs, with flags for user-contributed data > - tools to manage interaction between the official MFD database > (merge in their changes, send them our updates, etc.) > - mobile phone app to scan barcode, look up product in database (add > product if not found), look up warnings, update warnings > > Does that seem like an accurate assessment of the problem and a > reasonable sketch of a solution that'd handle it? > > +1 Minimum Viable Product: Database and a web-app that returns an HTML page for each barcode. Use RedLaser, pc2shop, or one of the other iPhone frameworks that can load a URL based on the barcode, and return a product/allergy summary. I like Tim's ideas around personalisation - I think it'd be easier for people to set that stuff up on the web (and easier to build). Some other stuff i found: Google open-sourced a barcode-reading toolkit, which is available on a few different platforms: http://code.google.com/p/zxing/ Discussion on iPhone barcode reading: http://stackoverflow.com/questions/838724/barcode-framework-for-the-iphone
On Fri, May 7, 2010 at 10:12 PM, Nathan Torkington <email obscured>> wrote:
> She's spoken to the MFD, who are keen to open their data. Many thanks
> to Mike for researching the GS1 barcode system. I need to test the
> GS1 lookup to see whether the manufacturers of supermarket-type
> products have uploaded their information to GS1. Even if the GS1
> database is a dud, the food allergy folks are up to crowdsourcing a
> barcode database for the food products that they care about. I'll bet
> we could even speak nicely to a supermarket chain and they'd help with
> that mapping.
Some thoughts for the functionality -- picking up each product one by
one and checking the ingredients is what i do already. (and my eyes
are pretty fast at finding the shape of the word/number i'm allergic
to). changing to scanning the barcode one by one isn't a huge
difference.
What i want is the reverse: "which of the 10 brands of corn chips can
i actually eat?"... the answer changes 5 or 6 times a year. They
really do change ingredients that frequently
P.S. I'm keen to help build this.
On 12/05/2010, at 1:29 PM, Brenda Wallace wrote:
> Some thoughts for the functionality -- picking up each product one by
> one and checking the ingredients is what i do already. (and my eyes
> are pretty fast at finding the shape of the word/number i'm allergic
> to). changing to scanning the barcode one by one isn't a huge
> difference.
That's great feedback. I'll hook you up, off the list, with the
person who kicked all this off, and we can bounce around needs and use
cases there.
> P.S. I'm keen to help build this.
MUSIC TO MY EARS.
On 12/05/2010, at 1:20 PM, Robert Coup wrote:
> Minimum Viable Product: Database and a web-app that returns an HTML
> page for
> each barcode.
True, I'd not thought about MVP yet. Re: toolkits, I'd done a heap of
research but I wanted to shop around the idea and the approach before
diving into implementation -- best to make sure we're solving the
right problem first :-)
On 12 May 2010 13:29, Brenda Wallace <email obscured>> wrote:
> On Fri, May 7, 2010 at 10:12 PM, Nathan Torkington <email obscured>>
> wrote:
> > She's spoken to the MFD, who are keen to open their data. Many thanks
> > to Mike for researching the GS1 barcode system. I need to test the
> > GS1 lookup to see whether the manufacturers of supermarket-type
> > products have uploaded their information to GS1. Even if the GS1
> > database is a dud, the food allergy folks are up to crowdsourcing a
> > barcode database for the food products that they care about. I'll bet
> > we could even speak nicely to a supermarket chain and they'd help with
> > that mapping.
>
>
> Some thoughts for the functionality -- picking up each product one by
> one and checking the ingredients is what i do already. (and my eyes
> are pretty fast at finding the shape of the word/number i'm allergic
> to). changing to scanning the barcode one by one isn't a huge
> difference.
>
>
Another possibility that would buy-in from POS manufacturers. Give people
their own card (or possibly, link with existing loyalty cards) with its own
barcode. The consumer's card is scanned at checkout. The POS machine then
pings the server and presents a warning to the consumer that there's a risk.
This I guess would be suitable for people that don't have phones or don't
want to waste time sending text messages. Have noted privacy / data sharing
concerns.
I probably spend a minute per new item of my shopping time looking for
random ingredients..
On 12 May 2010 14:17, Nathan Torkington <email obscured>> wrote: > On 12/05/2010, at 1:20 PM, Robert Coup wrote: > > Minimum Viable Product: Database and a web-app that returns an HTML > > page for > > each barcode. > > True, I'd not thought about MVP yet. Re: toolkits, I'd done a heap of > research but I wanted to shop around the idea and the approach before > diving into implementation -- best to make sure we're solving the > right problem first :-) > > Have just encountered Hadley Rich's (hads) in the #ubuntu-nz channel. I suggest followers to this thread view: http://foodstats.org.nz/ http://nice.net.nz/barcode/?string=opendataninjas
On 12/05/2010, at 2:34 PM, Tim McNamara wrote: > Have just encountered Hadley Rich's (hads) in the #ubuntu-nz > channel. I > suggest followers to this thread view: > > http://foodstats.org.nz/ > http://nice.net.nz/barcode/?string=opendataninjas Cool! Could you ask Hadley to join this list? Might as well concentrate the discussion here.
On 12/05/2010, at 2:50 PM, Brenda Wallace wrote:
> I'm still left with no confidence in the database, if it's only
> updated yearly.
> I'm going to have to read the ingredients anyway because the risks are
> too high to get it wrong.
I believe the reasoning was:
- you will *always* have to read the label. You don't want a
database error to kill you.
- so software should eliminate the pointless label-reading. In
other words, you should be able to quickly rule out products that
you're not compatible with, or zoom in on ones that you're probably
compatible with. Narrow the field so you're not reading when you
don't have to be.
On Wed, May 12, 2010 at 2:59 PM, Nathan Torkington <email obscured>> wrote:
> On 12/05/2010, at 2:50 PM, Brenda Wallace wrote:
>> I'm still left with no confidence in the database, if it's only
>> updated yearly.
>> I'm going to have to read the ingredients anyway because the risks are
>> too high to get it wrong.
>
> I believe the reasoning was:
> - you will *always* have to read the label. You don't want a
> database error to kill you.
> - so software should eliminate the pointless label-reading. In
> other words, you should be able to quickly rule out products that
> you're not compatible with, or zoom in on ones that you're probably
> compatible with. Narrow the field so you're not reading when you
> don't have to be.
Exposing the data as a web service sounds like phase 1 -- you'd need
for the eventual smartphone solution which can be phase 2.
This can then be made available to online retailers. The retailer can
query it themselves, or make a javascript snippet for your browser to
go fetch and display it on the page.
Then the "What's in that soup?" question is answered for online food
retailers. This is useful for people who want to be aware of what
they're eating, not just ppl with allergies.
Does the data extend to cosmetics too?
On Wed, 2010-05-12 at 14:49 +1200, Nathan Torkington wrote:
> Cool! Could you ask Hadley to join this list? Might as well
> concentrate the discussion here.
Hello :)
The FoodStats site is something I've been thinking about for a while but
only just really developed and put up from this weekend just gone. It's
still very much in the testing stage but starting to come together.
I've just added a couple of models to the database for Products (with
barcodes, sizes etc.) and Ingredients which relate to Foods. I haven't
added the UI for these just yet.
Once it's ready, I'd really love FoodStats to become a useful crowd
sourced database of food nutritional info and ingredients. All licensed
under a CC license with an API for use however people like.
Let me know what you think.
I couldn't help but notice that Foodstuffs was at the VUW ICT careers day the other week and didn't appear to be getting much attention from the punters who turned up looking for gainful employment. Maybe someone could could approach them with this kind of thing as a way to make themselves sexy, but to staff and customers? It would probably take more business smarts than I have... In the library / physical book world we use a lot of barcodes and a consumer-community has grown around the use of cuecats. See http://www.librarything.com/wiki/index.php/CueCat_barcode_scanning which includes a link to an open source java tool for decoding the output to an ISBN.
My understanding is that the barcode is the unique product ID, it doesnt
change. The product ingredient change would be alerted via GS1.net
I'd hope that GS1 would speak at the barcamp, so we can all learn how
their system works.
Regards Mike
Let me get this right. While the data would always be up-to-date, a shop
could have 2 cans of a product with slightly different recipes/ingredients
and the same barcode?
If so, this means the risk-adverse shopper could not rely on the data
derived from the barcode.
Would it be possible for the shopper to be alerted that a recent change has
occurred in the recipe/ingredients? This would alert them to the need for
additional checking.
I guess alerting them to the date of the last recipe/ingredient change, and
allowing them to check the versions for ingredients would work.
On Wed, May 12, 2010 at 4:49 PM, Brian Logan <email obscured>> wrote:
> Let me get this right. While the data would always be up-to-date, a shop
> could have 2 cans of a product with slightly different recipes/ingredients
> and the same barcode?
Given that food is required to have an expiry date, the max overlap
should be able to be worked out, yes?
The world is moving to individual item traceability, e.g. this specific can of baked beans. Here's some useful links: http://www.foodmanufacturing.com/scripts/Products-Impact-of-Food-Safety-Legislation.asp http://www.gs1.org/gsmp/kc/traceability The GS1 guys mentioned this, but they didn't go into detail about if the system was implemented yet. This all comes back to consumer visibility of the GTIN (barcode number) on all products, not just food. If you and I are both talking about a Samsung 40" LCD TV, are we talking about the same thing? There's no GTIN on the product (it might have been on the box). That's because up until now, GS1/suppliers/retailers assume there is no value to the consumer. Regards, Mike
On Wed, 2010-05-12 at 15:13 +1200, Hadley Rich wrote: > I've just added a couple of models to the database for Products (with > barcodes, sizes etc.) and Ingredients which relate to Foods. I haven't > added the UI for these just yet. Please excuse the self reply. I've just added ingredients to the food page; http://foodstats.org.nz/food/10145 You can specify the ingredients as a comma separated list when adding a food to the database, or, like tags, you can add them from the food page. You need to be logged in to see the add food dialog and to add tags/ingredients. I have products/barcodes in the database now too but need to implement the UI for that. I also need to finish the change auditing so I can enable editing of foods. Of course I probably need to work on some proper page layouts too at some stage etc. etc. Opinions welcome.
On 12/05/2010, at 3:11 PM, Brenda Wallace wrote:
> Does the data extend to cosmetics too?
The MFD doesn't contain cosmetics, only food.
On 12/05/2010, at 3:25 PM, Stuart A. Yeates wrote:
> I couldn't help but notice that Foodstuffs was at the VUW ICT careers
> day the other week and didn't appear to be getting much attention from
> the punters who turned up looking for gainful employment. Maybe
> someone could could approach them with this kind of thing as a way to
> make themselves sexy, but to staff and customers? It would probably
> take more business smarts than I have...
That's a good idea. If we turn out to need barcodes, we can
definitely pitch them on helping.
On 12/05/2010, at 4:49 PM, Brian Logan wrote:
> If so, this means the risk-adverse shopper could not rely on the data
> derived from the barcode.
Again, I say: the risk-averse shopper should never rely on software.
They take responsibility for their safety by reading the label. They
always will: nobody wants to die from a programming error. This is
true whether or not ingredient changes result in a new UPC.
On 12/05/2010, at 8:13 PM, Hadley Rich wrote: > Please excuse the self reply. I've just added ingredients to the food > page: > http://foodstats.org.nz/food/10145 Cool. Where's your data coming from? Is this all self-entered? If so, there seems to be a lot of overlap with the MFD. It'd be great to have everyone working together, rather than forking or cloning their database. They'll bring knowledge, manpower, connections to manufacturers, etc.
On Wed, 2010-05-12 at 22:19 +1200, Nathan Torkington wrote:
> Cool. Where's your data coming from? Is this all self-entered?
Yes, it's all hand entered at this stage.
> If so, there seems to be a lot of overlap with the MFD. It'd be great
> to have everyone working together, rather than forking or cloning
> their database. They'll bring knowledge, manpower, connections to
> manufacturers, etc.
More than happy to work together with anyone, including existing
organisations with data under a compatible license or just people who
want to contribute what's in their pantry.
On 12/05/10 10:17 PM, Nathan Torkington wrote:
> On 12/05/2010, at 4:49 PM, Brian Logan wrote:
>> If so, this means the risk-adverse shopper could not rely on the data
>> derived from the barcode.
>
> Again, I say: the risk-averse shopper should never rely on software.
> They take responsibility for their safety by reading the label. They
> always will: nobody wants to die from a programming error. This is
> true whether or not ingredient changes result in a new UPC.
>
Perhaps you could stop thinking of the "risk-averse" shopper and frame
it as the "at risk" shopper - it might help focus on what the issue is.
It might also be useful to include the "well informed shopper" who may well
be following the current fad or have an interest in what they and their
family are eating.
Regards
Doug Hunt
I'm thinking it would be useful if the user could program the scanning device to search for specific variables and present them in a simple GUI when found. So, for example, peanut allergies could set their handhelds to put up a PEANUT red flag. Something like this, only for food (thanks, Nat): http://schooloscope.com/
>
> Once it's ready, I'd really love FoodStats to become a useful crowd
> sourced database of food nutritional info and ingredients. All licensed
> under a CC license with an API for use however people like.
>
> Let me know what you think.
>
You may want to consider going to the US Department of Agriculture and
downloading their database. I know they have a massive database of
food items and their nutritional breakdowns.
On Thu, 2010-05-13 at 23:11 +1200, Tim Uckun wrote:
> You may want to consider going to the US Department of Agriculture and
> downloading their database. I know they have a massive database of
> food items and their nutritional breakdowns.
Thanks for the tip.
I've looked at the Food and Nutrition database. While it is very useful,
both raw and manufactured foods can and do differ quite a lot from
country to country.
hads
P.S. I've finished the change tracking code and enabled editing of foods
now.
In case anyone is still interested and keeping up. I've just added a bit more functionality; * Trace ingredients separately as well as ingredients * When adding a food you can now add the packaging info (400g can, barcode etc.) You can see an example here; http://foodstats.org.nz/product/9418705001016 If you click through to the ingredient it will show you foods which do or may contain it etc. The presentation of the data still has a way to go but the collection of the data is there so it can be worked on.