Although I also have regularly encountered two-character tags in RDF statements, the RDF concepts document  clearly does not preclude the use of 3-character tags or even complex tags like "zh-yue" or "tlh-Kore-AQ-fonipa" (phonetic transcription of Klingon using Korean script :-)).
The RDF document states that any valid language tag (referring to the relevant IETF doc, BCP47 ) can be used. That IETF document instructs one to tag languages at the level at which the information is useful, but not beyond. That obviously makes good sense. The fact is that there are languages (MANY!) that have no 2-letter code, at which point a three-letter code, or a tag and subtag, must be used. I suspect that the prevalence of two-letter codes has to do with who is providing linked data. Stats, however, show that some three-letter codes are being used. 
On 6/30/14, 11:41 AM, Simon Spero wrote:
This falls under the general problem of the use of strings instead of IRIs; different forms of code that are associated with the same "language" could be associated with an IRI referring to that "language" .
Alternatively, two Identifiers could be declared and asserted to be sameAs , but that approach is more complicated.
"Language" left unpacked to avoid issues of extended language tagsOn Jun 29, 2014 4:26 PM, "Stuart Yeates" <[log in to unmask]> wrote:
On 06/28/2014 01:25 AM, Jody L. DeRidder wrote:
I just saw this posted on Twitter.
Rob Sanderson is concerned about the ways in which Bibframe does NOT
worked in the linked data environment, and is trying to effectively
communicate the issues. He's asking for feedback:
My biggest issue (that's not covered in the doc, but which I've already fed to the doc's authors) is that BIBFRAME mandates three-letter language codes, where available, while core RDA mandates two-letter language codes, where available.
This requires every app that wants to interoparate BIBFRAME with any thing else (and indeed any app that wants to compare BIBFRAME language codes with the language codes on RDF plain-text labels) to have extensive lookup tables.
-- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet