 |
 |
On Sun, 1 Dec 1996, Terry Allen wrote: > 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. We was the us on this mailing list, a superset of the us that attended the Warwick meeting (and probably the Dublin meeting as well, though this list wasn't around then). I, and a number of others, think that we have a nice consensus mechanism going on this list; we are feeding back on documents and seem to be making real progress. No one person or organisation "owns" DC or has any authority over it in my mind; it something that we've all been working on as a collective. If I'm out of line on this then I hope someone will say so as I don't want to keep busting my butt to work on something which isn't going to be openly defined and available (which is why I've advertised this mailing list in other groups when I thought it appropriate). I don't want to find that we suddenly have "Wilbur situation" dumped on us like the W3C did with HTML 3.0. > | (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. The element is Author, not AuthorName. I _do_ expect DC to provide the ability to encode lots of other _types_ of information about authors in the Author element, including such things as email, affliliation, postal address and home phone numbers. The default can be to assume that the Author element contains the author's name, but I, and others I think, want the ability to use the Type qualifier to add in this other information. If you don't then that's fine; just use the default "name only" qualifier-less version and you'll be smiling as well. > | 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. Err, this is in the first version of DC (not the User Guide version). Or did you mean in the original DC meeting report at OCLC? I didn't think that specified a concrete representation or canonical list of qualifiers and qualifier-values? I seem to remember we spent much time at Warwick and much time since then working on just those issues. Am I out of line again? > 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. The idea (I thought) was to come up with a list recognised qualifier name/value pairs which is what I and others have been steadily doing over the months. If someone uses a non-standard qualifier or qualifier-value they should use an "x-" prefix but even if they don't, software is free to ignore qualifiers that it doesn't understand. No harm done there. > 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. So we either have millions of elements (MARC?) or a few elements with sensible defaults and qualifiers to give us expandability (DC). Doesn't seem alot in it to me and qualifiers are what we've had since the original DC documents. Sorry, but I just can't see a reason to suddenly switch to the "let a thousand elements flourish" view now. But I'm willing to go with the consensus if there's a groundswelling in that direction on the mailing list. Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. *