Perhaps you're right. Given the history of the 050 data we see (not just typos, but deliberately using it for something else), I think it's best if we put it into some other property. That keeps the class property clean and tells you that the data came from there but is not correct.
Nate
-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Thomas Dukleth
Sent: Wednesday, June 19, 2013 9:58 AM
To: [log in to unmask]
Subject: [BIBFRAME] Avoid silently dropping data
[Original Subject: Re: [BIBFRAME] 050 multiple $a's]
[Subject changed to appropriate topic for present message.]
Data should not be silently dropped merely because it has been poorly coded or is otherwise invalid. Some degree of such data is contained within our collective legacy records.
We ought to preserve the meaning of all our source data in some manner and where an automated conversion fails to identify some source data as valid it should be preserved and designated as invalid as some associated part of the converted collection of RDF values. All necessary provenance should be recorded for both valid and invalid data in some annotation such as source record identifier, processing program identifier, processing program version number, and data insertion date.
Data which is invalid might be corrected at a later date even automatically by an improved processing program. A particular processing program version may even have a bug which incorrectly identifies some valid data as invalid.
There was some treatment of the issue of bad data in the On BIBFRAME Authority discussion paper, http://bibframe.org/documentation/bibframe-authority/ .
Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
+1 212-674-3783
[Original Subject: Re: [BIBFRAME] 050 multiple $a's]
On Tue, June 18, 2013 20:26, Trail, Nate wrote:
> You're right, but the "secondA" was ignored not because it was the
> second $a, but because it wasn't valid. Repeating the first (valid) $a
> would work, even if it wasn't a "real" record.
> Nate
[...]
|