LISTSERV mailing list manager LISTSERV 16.0

Help for DATETIME Archives


DATETIME Archives

DATETIME Archives


DATETIME@C4VLPLISTSERV01.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DATETIME Home

DATETIME Home

DATETIME  November 2010

DATETIME November 2010

Subject:

Re: Proposal to change unknown marker from 'u' to 'x'

From:

"Edward C. Zimmermann" <[log in to unmask]>

Reply-To:

Discussion of the Developing Date/Time Standards <[log in to unmask]>

Date:

Tue, 23 Nov 2010 14:31:54 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (124 lines)

On Tue, 23 Nov 2010 11:44:16 +0100, Jakob Voss wrote
> Edward C. Zimmermann wrote:
> 
> > I personally do not like x. I see nothing to gain from using x.
> 
> I summarized the arguments in my first mail. But arguments about 
> notation always depend on cultural background. We could also use 

Its about information processing and computers and not about "cultural
background". 

> random characters or codes instead of '~', '?', '(', ')' etc. It's

These characters are not random. 
 
> mostly about what you consider more convenient in which context.
> 
> > 1) MARC21  (the harmonized US and Canadian MAchine-Readable Cataloguing
> > standard) uses u for uncertain or missing digits in its date fields. That
> > format is the North American standard. It won't go away and its significance
> > is not limited to North America. This means that many of us must already
> > support u in this function.
> 
> So your context is MARC21, and in this context there is an argument 
> for using the letter 'u' in this place. But everywhere outside the 
> heavily outdated world of MARC, this practise is unknown and 'x'

And those books too in the old library.. all old and outdated... Who needs
them when one has Wikipedia and Google :-)

What alternative to you offer to MARC? 

> would be the more natural choice.

There is no wide practice of using 'x' represent an unknown cell or space to
fill. In fact, if one wants to appeal to cultural semantics... 'x' is really
the wrong character. 

The cultural information processing heritage of 'x' stems from typewriters and
overtyping: the act of "crossing out". Its to strike out or remove something.

There are other cultural semantics for 'x'. Our 'x' as taught in school
algebra--- and its not just x but also y, z, alpha, beta, delta and omega---
is not really a concrete object but in the sense of Descartes an
abstraction--- see also Arabic and Greek mathematics (of which the selection
of 'x' had its rooting). The symbol is also taught in school as concrete
multiplication: 10x5 (abstract multiplication given the common use of 'x' in
school textbooks for variable names demands the use of other notations for
multiplication).

'X' is also the symbol or enemy, ritual friend (Homer: xenos) but also
crucifixion, the spot on the map where the treasure is buried, a person's
signature. the number 10 and .... lets not forget XXX as ...



> 
> > 2) Worse still is the observation that x is also commonly used in the first
> > position to represent hexadecimal codes.
> 
> I don't see this as a problem, as we don't support hexadecimal codes 
> in the standard. Escape sequences do not use a single 'x' anyway,

If I announce that something is a date perhaps... But how do we teach
computers to recognize dates?

>  but some other escape character like backslash or ampersand,
>  combined with 'x' or some other characters.
> 
> > What does 'x' deliver other than, at best, additional complication? Our
> > formats are, after all, primarily for computers. In library systems characters
> > such as '#', 'u' and '?' have been used. The character 'u' is not my
> > favorite--- but understandable in MARC21 given the heavy use of punctuation
> > characters for significant functions--- but clearly preferable to 'x'.
> >
> > In this context I think we might also want to consider the difference between
> > unknown digits and a placeholder for a date (fill characters such as | in
MARC).
> 
> Sorry, but arguing with special properties of MARC is like arguing 
> with special properties of EBCDIC, troff, or any other standards 

EDCDIC is a proprietary character encoding standard that was once advocated by
IBM. Its been widely replaced by other encodings and standardization of
keyboards--- back into the 1970s on many computers one needed a specific
proprietary keyboard to program them (this was one of the chief motivations
behind BCPL and why it grew with the ARPAnet).

MARC21 is a current accepted standard for the interchange of bibliographic
information.

Fortran too is "old school" from the 1950s.. over 50 years old and with a vast
legacy. Its still the primary language for a large body of applications in the
scientific community!

> from the 1960s. I would even argue that having a special property in 
> MARC, it is a good indicator that you do not want it in any serious 
> current application. Or more drastically: MARC is a pest, that 
> current Date/Time standards should not be infected with.

You keep attacking MARC--- and MARC21 is where a lot of the MARCs are now
headed--- but what replacement have you suggested? 


> 
> Jakob
> 
> -- 
> Jakob Vo▀ <[log in to unmask]>, skype: nichtich
> Verbundzentrale des GBV (VZG) / Common Library Network
> Platz der Goettinger Sieben 1, 37073 G÷ttingen, Germany
> +49 (0)551 39-10242, http://www.gbv.de


--

Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
Office Leo (R&D):
  Leopoldstrasse 53-55, D-80802 Munich,
  Federal Republic of Germany
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 2019
February 2019
December 2018
November 2018
October 2018
January 2018
August 2017
July 2017
June 2017
April 2017
March 2017
February 2017
August 2016
July 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
December 2014
November 2014
March 2014
September 2013
May 2013
February 2013
October 2012
September 2012
August 2012
May 2012
March 2012
December 2011
November 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
February 2010
January 2010
December 2009
November 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager