 |
 |
On Sun, 1 Dec 1996, Terry Allen wrote: > Jon Knight writes: > | >> We've had "Affiliation" down as a value of the Type qualifier for > | >> Author > | > I think this is the wrong tack. > | > http://www.oclc.org:5046/oclc/research/conferences/metadata/dublin_core_report.html > | > > | > | No, but the original report is well over a year and a half old now and I > | think we've moved things on a bit since then. > > Who is we, where is we's consensus authoritatively expressed? When did > "we" decided to add Type to Author at all? What set of values were > proposed for a Type qualifier when "we" decided to add it? Maybe > I missed something. > > | > , and indeed the example given > | > would suggest that one stuffs all that address info into the content > | > of Author or leaves it out: > | > > | > Author (scheme=USMARC) = 100 1 Doyle, Author Conan $c Sir, $d 1859-1930 > | > | In this example we've got a Scheme qualifier so we already know that the > | metadata that's inserted corresponds to an external structuring convention > | (in this USMARC). I view Type qualifiers as being there for the times > | when people don't have an external Scheme to reference, or maybe even if > | they wish to emphasis which part of an external scheme that they're using. > > Irrelevant to the fact that Email is not a type of Author. You are > opening the door to mixing in with author names any kind of information > at all related to the Author (number-of-children, other-books-written, > favorite-color, campaign-slogan), which degrades the ability > to extract author name info (the stuff we need most and the content > originally defined for this element) reliably from DC records. In the MARC example above, > | > (assuming a typo there after the first comma ...) where Doyle's dates > | > would be replaced or augmented by his email address. Email address > | > is not a type of author, it's information for which no specific slot > | > has been provided in DC (along with much else). Nor is OtherAgent > | > expected to be something about Author. Lee is right that there's > | > no way to *encode* this info in DC:Author; that's okay. > | > | Well I think that there _is_ a way to encode this information; according > | to Paul Miller's "Metadata for the Masses" article use of Type & Scheme it > | would be something like: > | > | <META NAME="DC.author" CONTENT="(TYPE=name) Jon Knight"> > | <META NAME="DC.author" CONTENT="(TYPE=email) [log in to unmask]"> > | <META NAME="DC.author" CONTENT="(TYPE=affiliation) Dept. Computer Studies, > | Loughborough University"> > > This way of encoding the information (aside from the syntax-within-a-syntax) > confuses any user agent that assumes the original semantics of DC; > such a user agent will produce results indicating that your name is > (TYPE=name) Jon Knight. If it fails to handle the values supplied for > TYPE, it will additionally indicate that you have two coauthors. It also > leaves you no way to provide author address data for multiple authors. > And, if extended, it leads to people supplying their own values for > TYPE, e.g., > > <META NAME="DC-1.1-author" CONTENT="(TYPE=firstname) Jon"> > <META NAME="DC-1.1-author" CONTENT="(TYPE=surname) Knight"> > > that will produce incorrect results when input to any user agent that > can handle only the delimited list of values you think should be used. > > It's a classic case of tag abuse. > > Tag abuse often points to inadequate underlying semantics, and that's > just what we have here. I reiterate that you can solve the problem > effectively by adding elements, adding a qualifier for a pointer to > author address information, or (for now, and what I recommend) > supplying the info outside the DC set. Abusing the Author element > only weakens DC's semantics and their real-world utility. > > > Terry Allen Fujitsu Software Corp. [log in to unmask] > "In going on with these experiments, how many pretty systems do we build, > which we soon find outselves obliged to destroy?" - Benjamin Franklin > A Davenport Group Sponsor: http://www.ora.com/davenport/index.html > Giving information such as author's email, affiliation, etc. one reason why many years ago a MARC authority format was created. It was judged inappropriate to cram all that information in a record for a bibliographic item when it related only to the author's name. Thus the MARC authority format has elements to help the user identify the author for which the record was created. Some of the elements in the author's name field (e.g. date) serve to distinguish the person from someone else with the same name. I agree that this is an abuse of the tag "Author" and belongs instead in a pointer to additional information about the author. Rebecca ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ Rebecca S. Guenther ^^ ^^ Senior MARC Standards Specialist ^^ ^^ Network Development and MARC Standards Office ^^ ^^ Library of Congress ^^ ^^ Washington, DC 20540-4020 ^^ ^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^ ^^ [log in to unmask] ^^ ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^