I agree with Saašha - that "or" in the definition is a red flag.
Especially since it is now known that this data must be transformed into
whatever the new framework will be, and working with single elements
that can have multiple types of values will have make that
transformation less accurate. This will need to be at least 3 different
assigned elements.

kc

On 5/23/12 5:20 PM, Saašha Metsärantala wrote:
> Hello!
>
> Regarding
> 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 "parallelrecordcopy".
>
> 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.
>
> Regards!
>
> Saašha,

--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet