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,
> 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.