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