Ron Daniel Jr. wrote:
>
>
> The rule "unqualified elements are to be regarded as free text" means
> that we can't *require* that unqualified occurances of Date
> are to intepreted as "date of issue". The example above about the
> date of the Esperanto translation shows this.
>
> However, it can certainly be recommended practice that if people provide
> an unqualified date, that should be its meaning. We can also recommend
> that people provide a qualifier to make that explicit.
>
I was thinking (a bit simple minded no doubt) of the following
(suggestion).
Marking up a DC record with as many dates, that are considered relevant
by the DC record creator, would enhance the chance that in the searching
phase (when searching on date) that record will be discovered.
Actually, the *searcher* for a resource will give meaning to the DATE
field. He decides, that he wants to discover a resource with a specific
date. And as long as this date, whatever kind of date this is, is in the
DC record, he will succeed in discovering it, and he will be satisfied.
There seems to be no need to qualify the date in the DC record, the
searcher found the resource anyhow, only because the date he required
was present in the DC record.
This means that all the relevant dates (and in practice this will not be
a lot; the average DC creator will not be able to relate a lot of dates
to a resource, only theory will.) will have to be put in different DATE
fields (DATE is repeatable anyhow).
To enhance the discoverability the date content format could be
structured.
I am assuming that all dates from the different unqualified date fields
will be tossed into one index, which will be the predominant situation
in practice, I assume.
> People, being people, will do what they want. Therefore if I get
> an incoming DC record with an unqualified date, I may treat it as
> "free text" which is essentially your notion of "host choice". Further,
> Date elements with qualifiers that I don't understand can also be
> treated as free text.
>
> As a practical matter, I'd expect people to just toss all the contents of
> Date fields into a field of their full-text index. Only organizations
> with well-established date types that serve an ongoing business need will
> bother to keep them distinct.
--
Frank A. Roos ([log in to unmask])
|