Lee writes:
| > (TYPE=name) Jon Knight.
|
| The "original semantics" as expresed at the Dublin, Ohio meeting (I was
| told afterwards) did not include a syntax. The syntax used here is close
| to what was suggested at Warwick, and has already been discussed on this
| list.
What I find in
http://www.nlc-bnc.ca/ifla/documents/libraries/cataloging/metadata/dublin2.htm,
"A syntax for Dublin core Metadata: Recommenda..." is an example using such
syntax and a statement of consensus for using HTML META. The good authors
don't even provide a recommended production to describe the parenthetic
syntax. It's just presented as a possibility. I think it's still worth
warning against trying to nest an admittedly "arbitrary syntax" within
HTML, especially if it is meant to disambiguate diluted semantics.
| One reason that I had for bringing up author affiliation is that it
| is frequently present in existing bibliographical databases -- e.g.
| bibtex, texbib, refer, bib, etc. all have it -- and the ability to
| encode it may aid conversion, and hence encourage people to use the
| information, e.g. when they publush their own papers, or in making
| older documents available. It was also a good example of something
| on the edge of the DC.
|
| I am not sure if it's abusing the Author field. I originaly saw the
| author's institutional affiliation as an OtherAgent.
The OtherAgent is supposed to be "The person(s), such as editors and
transcribers, who have made other significant intellectual contributions
to the work," which is something different. Even if the institution
supports the author's work materially, it's much more like (names
from Docbook, concepts from Majour, a good reference point)
Collab, ConfGroup, ContractSponsor. And if not you might well want Affil
to be in some other subgroup along with the Author's address info.
So even if you want to reinvent the wheel of personal contact info and
biodata representation, recognize that it is usefully put into a
different place than the Author's name.
| We can decide how to encode author affiliation and say so, and if
| we say it is part of Author, it isn't tag abuse. Of course, if
| we put it into a field called "DATE", people will look at us oddly,
| so it does have to be at least marginally plausible.
It's tag abuse because it waters down the semantics of Author
(Author's name) and, as can be seen from the HTML Jon Knight supplied,
it makes it more difficult to extract information from the
(still underpowered) combination of attribute names, attribute
values, and internal, non-HTML syntax (in syntax-free DCese,
element name, qualifier names, and a potentially uncontrolled
range of qualifier values).
I grant that you can reserve TYPE=name for the case now covered
by Author, but you still don't have a way to associate miscellaneous
author information with the author's name, a problem neither you
nor Jon answered. Yet if you add a pointer as a qualifier on
Author, you get precisely the association you need. That shows
that the tag abuse is deleterious.
Jon Knight writes:
| >
| > 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
Yes, 0.1 (I miscalled it 1.0 recently).
| 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?
I Wasn't at Warwick, and have been unable to get a clear fix on what was
*decided* there. There's been a lot of discussion and further work;
isn't that all by way of presenting proposals to modify and extend DC 0.1?
DC 0.1 doesn't specify a concrete representation (perhaps its highest
virtue), but it does supply a list of elements and what we're now
calling qualifiers, all with definitions, without a list of qualifier
values.
I take it that you are proposing a change to the definition of Author
in 0.1, and that the User Guide we discussed here recently is also
such a proposal. If not, please put me right.
Regards,
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
|