W3C home > Mailing lists > Public > uri@w3.org > April 2010

Re: URIs in QR

From: Erik Wilde <dret@berkeley.edu>
Date: Thu, 08 Apr 2010 11:40:17 -0700
Message-ID: <4BBE2311.5050801@berkeley.edu>
To: uri@w3.org
CC: Dan Brickley <danbri@danbri.org>, Sandro Hawke <sandro@w3.org>, Bob Aman <bobaman@google.com>, wot@webofthings.com
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.
Received on Thursday, 8 April 2010 18:40:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC