Re: URIs in QR

Hello everybody,

Living in Japan, I'm a bit surprised that QR codes suddenly seem to be 
so 'in'. There are definitely quite a few around here in Japan, but not 
that all the walls are covered with them.

The extraction of URIs from QR codes seems to work about as well (or not 
well) as extraction of URIs from email. Definitely your email reader's 
mileage may vary quite a bit with respect to what it recognizes and what 
not.

As for 'tying URIs/URI schemes to applications', some advice (and maybe 
actual standards work if that prooves necessary) about how to avoid the 
problems with URI scheme proliferation due to application proliferation 
(what started with iTunes and now continues with iPhone and so on) would 
be very helpful. I don't see much other items of work for this area, 
because even in the PC world, it's the user's business of how to 
configure this association.

When QR codes were reasonably new here in Japan (must have been quite a 
few years back), I looked into what W3C might be able (or need) to do 
for them, but at that time, I got told that there was no pressing need 
for further standardization. I don't know whether this might have 
changed in the meantime.

What I seem to remember was that QR codes were defined only for ASCII 
and for Shift_JIS; ideally, they should use UTF-8, of course.

Regards,    Martin.

On 2010/04/09 3:40, Erik Wilde wrote:
> hello all.
>
>> Yes, the use of URIs in QR struck me as rather ad-hoc too, relying on
>> heuristics too often.
>
> this certainly is the case, and why i haven't done any systematic study,
> the few apps that i tried on mobile devices all seemed to use their own
> methods and conventions, and most of them were not as robust and generic
> and configurable as they should be (if they were trying to be useful as
> general-purpose QR apps). i would be hard-pressed to exactly define what
> "robust and generic and configurable" means, though, and it seems to me
> that answering this question could be very valuable.
>
>> I've often thought we should do this, but only recently got my hands
>> dirty coding (integrated a QR reader into an iPhone app).
>
> i still hope to see QR support popping up in mobile OS platforms, and
> since there's an open one out there, if somebody is really adventurous,
> that would be a very interesting exercise to go through...
>
>> I don't know the status of QR Codes as a spec, in terms of things like
>> public availability of the standards docs, royalty free status, etc.
>> etc. http://en.wikipedia.org/wiki/QR_Code#Standards suggests "NTT
>> docomo has established de facto standards for the encoding of URLs,
>> contact information, and several other data types" but the use of
>> "URL" rather than "URI" doesn't fill me with confidence that the work
>> is 100% done. But even having a 'state of the landscape' document
>> (rather than something standards-like) could be a huge help for
>> everyone. Although an XG is a good idea and I'd try to participate,
>> for now I'd settle for a fact-pooling Wiki page...
>
> my take on this is that wikis tend to be much less useful that actual
> deliverables with a well-defined set of what should be covered, and by
> when. maybe we could have an QR dinner at www2010 and see how we might
> best proceed with this?
>
>> Have a play with http://github.com/diva/digital-voices/
>> http://www.youtube.com/watch?v=cjnPwV6yP6o
>> http://www.ics.uci.edu/~lopes/dv/dv.html too, especially the birdsong
>> encoding I think is quite lovely -
>> http://www.ics.uci.edu/~lopes/dv/BirdInfo.wav - you could have similar
>> software scanning audio going through your machine looking for secret
>> codes in radio jingles, youtube videos etc...
>
> i did not know of this. pretty amazing. so, instead of looking at QR,
> probably it would make sense to say what to best in real-world
> representations of "web-friendly handles", and then QR or audio would
> just be different representations. QR is ISO and thus may be a little
> further along that the audio encodings, but generally speaking,
> connecting the real world and the web should probably work in the same
> way for both representation types.
>
>> I think there's a lot to be gained here around mobile apps, eg. to
>> avoid a proliferation of barcodes outside points of interest (shops,
>> restaurants etc) I hope we'll see a move towards a single barcode that
>> is for a page describing the location, and embedded RDFa to make that
>> description machine-readable.
>
> this idea will make facebook or google very happy. have a sole provider
> of identity and everything goes through them. i think how web-friendly
> real-world encodings will be used should not be prescribed in any way,
> but we need to make sure that the web architecture parts of it work ina
> well-defined way.
>
>> Can you advise on the options when a W3C work item is heavily based
>> around work already standardised elsewhere? Are there formal
>> conventions/constraints already, or just social conventions like -
>> play nice and establish friendly liaison?
>
> my take is that this is basically the same as almost all web stuff using
> unicode; unicode is stable and that's all that matters. the same can be
> said for QR. it's an ISO standard and that's all that matters (maybe not
> quite giving IP issues, but at least from the technical perspective).
>
>> A lot of QR use does seem to be to discover identifiers. My guess is
>> that heuristics are doing 80%+ of the work just fine, so there hasn't
>> been a strong driver to 'catch up with the paperwork' and say exactly
>> how this should work.
>
> all of the apps i tried work in some cases and not in others. many get
> URI decoding wrong with non-ASCII URIs or even with "+" signs in them.
> many don't recognize non-HTTP(S) URIs. many have no way of associating
> schemes with apps. all of this is not rocket science, but it might help
> the ecosystem a lot to tell developers what they're supposed to do if
> they want to support not only QR scanning, but also the mobile web.
>
> cheers,
>
> dret.
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Friday, 9 April 2010 07:05:11 UTC