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  August 2012

DATETIME August 2012

Subject:

Re: Two questions about the draft

From:

Go Sugimoto <[log in to unmask]>

Reply-To:

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

Date:

Thu, 30 Aug 2012 10:29:06 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (110 lines)

Dear Ray,

Thank you very much for anwering my questions. Interesting.

>>I don't understand what you mean by saying that you find ~ "confusing, because it looks like starting of period."

In the spec, the syntax "1980~" means approximately 1980, right?
But, it looks (to me at least) like to mean "from the year 1980 onward" (i.e. 1980/open is the equivallent in the spec).
It is also consuging to compare this with a local convention that people sometimes use(e.g. "1980-" often means 1980/open)
 
I perfectly understand the intention of using one character, and I support it.
I am only wondering if there would be better characters than "~", without interfering pre-defined XML character sets, 
yet being more human-friendly. It is not easy, yes. What I could think of now are:

c1980 (approximately 1980)
c1980? (approximately 1980, but uncertain)

or

1980@ (approximately 1980)
1980@? (approximately 1980, but uncertain)

>>"'196x' has decade precision while '196u' has year precision". 

Maybe I am not smart enough, but this is what I don't understand very well. The spc also says in the same paragraph "Both represent an unspecified year during the 1960s, but for 196x the year is not supplied because it is known only with decade precision..." So, fundamentally, both represents a year sometime during 1960s, doesn't it? I see the difference of the two only by the needs of the cataloguer, rather than the matter of precision.

In my understanding, the precision is decided by the cataloguer's choice: 
1) if she thinks the decade (1960's) is enough precision for the purpse (i.e. 196x. My Rubik Cube case) 
2) if she hopes or needs to have the precise year of 1960's in the future (i.e. 196u. My archaeology case, for example expecting a radio-carbon analysis).

If my argument is right, then the precision does not seem to be the way how this distinction should be made.
Or, am I still not getting the point?

>> You might want to look through the archive of the email discussion on this. 

I will try. It would be great if you can give some hint (approximately when it was discussed).


P.S. I will be away for a while and can not reply soon, but will have a look and come back, if the ball will be rolling.

Many thanks,
Go Sugimoto


-----Oorspronkelijk bericht-----
Van: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] Namens Ray Denenberg, Library of Congress
Verzonden: woensdag 29 augustus 2012 23:45
Aan: [log in to unmask]
Onderwerp: Re: Two questions about the draft

Go - Thank's much for your comments.

From: Go Sugimoto
> 1) Is ~ the only possiblity to express approximate date? For computer 
> processing, there is no problem, but thinking of human-usability, It 
> is rather confusing, because it looks like starting of period.
> Wasn't it an option to use c/ca (circa) or a (approximate) or 
> something similar? As far as th terms like "unknown" and "open" are 
> introduced, I don't see the problem to use characters to be a bit more human-friendly.

I don't think there was ever any discussion or debate about what
character(s) would represent approximate date. (There was much discussion and debate about what is meant by "approximate date", but not about how to represent it.)  So I can only tell you my view on why ~ was chosen.  Mainly, we wanted a one-character symbol. 'ca' is sufficiently suggestive of "approximate" but it is two characters. Neither 'c' nor 'a' is sufficiently suggestive (nor would any single letter be). We wanted a one-character symbol because it is used in conjunction with other symbols (in contrast with "open" and "unknown"), as in for example "?~" and two characters for the approximation symbol would have increased parsing complexity.

I don't understand what you mean by saying that you find ~ "confusing, because it looks like starting of period."

 
> 2) There is a paragraph about the use of x and u:
> 
> Note the difference in semantics between 'x' and 'u'. '196x' has 
> decade precision while '196u' has year precision. Both represent an 
> unspecified year during the 1960s, but for 196x the year is not 
> supplied because it is known only with decade precision. In contrast, 
> for 196u the year is not supplied for reasons that are not specified 
> but there is some expectation (though no guarantee) that the year may 
> be supplied later; for 196x there is no such expectation.
> 
> I am not very sure the diference comes from decade and year precision 
> (both seems to have exactly the same meaning: an unspecified year 
> during 1960's), but I would think that the intention is different.
> 
> Maybe I am confused with the English phrases, but if I read between 
> the line, I might think this way: "expectation" may be a bit confusing 
> term in the paragraph.
> For example, on one hand, in archaeology (Im originally an 
> archaeologist ;) ), it would be great if scientific analysis brings 
> more precise date of an object later, so there is expectation. In my 
> view, this is kind of normal situation and there is always a chance 
> for unexpected scientific of academic discovery and date can be found 
> later. On the other hand, if there is a photo dipicting some Rubik's 
> Cubes. A curator knows that they are all from 80's production, but 
> s/he does not need to specify more in order to display it as typical 
> 80's toy. Then, the date is 198x, and the point is that there is no 
> intention to investigate all the production dates in future; hence 
> there is no need to be precise. So what about this?
> 
> Note the difference in semantics between 'x' and 'u'. Both represent 
> an unspecified year during the 1960s, but for 196x the year is not 
> supplied because there is no intention or need to be more specific. In 
> contrast,
for
> 196u the year is not supplied for reasons that are not specified but 
> there is some expectation or need (though no guarantee) that the year 
> may be supplied later.

The essence of the existing text is "'196x' has decade precision while '196u' has year precision". Your suggested revision eliminates that distinction (and introduces a different distinction). During discussion and debate on this, there was only one participant who felt that this distinction is meaningful (or at least meaningful enough that it be represented in the spec). But for that one participant this distinction is critical. (Perhaps he will weigh in further.)  In fact crafting that text so that everyone was satisfied was possibly the most difficult part of the process of developing the spec. You might want to look through the archive of the email discussion on this.  But in any case, you will have the opportunity to revive this issue during the next phase, which I hope to have more information on soon. 

Thanks again.

--Ray

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