http://www.loc.gov/marc/marbi/2012/2012-03.html I noticed that the
subfield $u is aimed to contain:
> a URI, a process name, or some other description.
My suggestion is to populate $u subfields exclusively with URIs, whereas
any other description would be stored in another subfield, toghether with
the RFC 5646 code of the language used. I also suggest to use appropriate
URIs to identify process names such as "autodewey", "classify" and
Textual description in a human language may need to be translated to
another human language. It is important to be able to easily identify what
may need to be translated. For example: If the content of this subfield is
to be included in a future version of MODS or other XML documents, it is
appreciable to be able to identify it easily with XSLT without the use of
RegEx checking whether it is a URI or not - such regexes are not trivial
if they are to be really accurate and they run rather slowly. This is also
important if ITS is to be used on files containing data from $u subfields.
On the other hand, an (xlink or html) link may need to be created for end
users if $u content is a URI. Non-URI text would result in broken links.
If the content of such subfields is to be used for LD, it is also
important to be able to easily identify whether it is a URI or not.
The human readable text provided by web servers as a reply to a HTTP
request may be translated when needed through content negotiation based on
the Accept-Language request header, for example. Other content negotiation
may be used to serve different file formats. In other words, a URI is
rather different from a description in a human language and I consider
that we should avoid to mix them.