I always ask what purpose a bit of information serves. If email addresses change
(and they do a lot), what purpose is it in a metadata record? It can't be used to
identify the person, while institutional information could be useful [e.g. this
person used to work at Northwestern University in the Classics Department and is
now at Harvard in the Classics Department--probably the same person].
But [log in to unmask] or even [log in to unmask] gives no genuine information.
If the email address is supposed to be used as a point of contact, i.e., to be
able to email someone, then we will be taking the responsibility of maintaining
that email address, which is equivalent to keeping a phone book. This could
consume a massive amount of time, when, if the creator wants to be contacted s/he
can always place the email address on their actual webpage, somewhere.
Yes, it might be *nice* to have this sort of information in the catalog--it would
be nice to be able to tell someone where they can buy a copy of a certain book,
for instance--but the system is not made for that.
So, I personally see no useful purpose to an email qualifier. I think such things
should rather go into a handbook on "Good Style for Website Creators." e.g. "If
you want someone to contact you, put your email address into your webpage
somewhere in a prominent location." But email addresses should not be in a
metadata record.
The eternal skeptic and nay-sayer(!)
Jim Weinheimer
Princeton University
[log in to unmask]
Robin Wendler wrote:
> Hi, Peter --
>
> The argument (not advanced by me, but I take the point) has been that
> a person's name is no more "the person" than his e-mail address is -- it's
> just a label for the person. Of course, people change e-mail addresses
> more often than they change names, but the principle still applies. If you
> accept that premise, than e-mail address does not violate the semantics
> of the creator element (Canberra Qualifiers), nor does it violate 1:1.
>
> However,something like mailing address (22 Cross Street, Northville, NY)
> can in no way serve a comparable purpose, and therefore does violate, to
> my mind, the Canberra Qualifiers rule, and in your argument, 1:1.
>
> Im happy to propose that we are both right.
>
> --Robin
>
> On Mon, 26 Jul 1999 [log in to unmask] wrote:
>
> > Robin -
> >
> > I've never seen a succinct definition of the 1:1 rule. Those of us who
> > came in after the original discussions have had to piece it together from
> > context ... (_please_ someone whose got a better understanding jump in at
> > any time) ... but ...
> >
> > As I understand it, the 1:1 rule deals with only including metadata that
> > applies to the instantiation of the resource "in hand". It is usually
> > thought of in terms of related resources. Hence, if a resource has a
> > relationship with a second resource. it may reference the second resource,
> > but it should not include metadata from that resource (unless that metadata
> > is also directly applicable). If people (or applications/search engines)
> > want more information (metadata) about the related resource, they must
> > follow the link to that resource.
> >
> > For example, suppose we have a resource called "Article A" by Suzy Smith
> > and a second resource called "Article B" by John Doe. If Article B is
> > based on Article A, as I understand it, the 1:1 rule tells us that we
> > should indicate the relationship in Article B's metadata:
> >
> > DC.Title = "Article B"
> > DC.Relation.IsBasedOn = "Article A"
> >
> > but that we should stop short of including any other Article A metadata.
> > For example, if you want the author of Article A, you would have to go to
> > Article A's metadata to get it. You would _NOT_ add an Article B metadata
> > field like DC.Relation.IsBasedOn.Creator = "Suzy Smith". Simply put, even
> > though there is a relationship between the resources, Article A's author
> > does not belong in, nor should it be repeated in Article B's metadata.
> >
> > So what's the parallel to, for example Creator.EmailAddress?
> >
> > >From a conceptual perspective, the agent qualifiers can be thought of as
> > special cases of the Relation qualifier in so far as they name a related
> > resource where the relationship is that the named resource created,
> > published or contributed to the current resource. For example, the DC 1.0
> > notion of Creator could conceptually be expressed as Relation.WasCreatedBy,
> > (if there were such a subelement). Hence
> >
> > DC.Title = "Article B"
> > DC.Creator = "John Doe"
> >
> > could be represented as
> >
> > DC.Title = "Article B"
> > DC.Relation.WasCreatedBy = "John Doe"
> >
> > Hence, adding DC.Creator.EmailAddress would be tantamount to adding
> > DC.Relation.WasCreatedBy.EmailAddress (like DC.Relation.IsBasedOn.Creator).
> >
> > John Doe's e-mail address is part of the metadata that describes the second
> > resource Johh Doe, not part of the metadata that describes Article B.
> > John's e-mail address has no more business in Article B's metadata than the
> > Article A's author does. (IMHO)
> >
> >
> >
>
> Robin Wendler ........................ work (617) 495-3724
> Office for Information Systems ....... fax (617) 495-0491
> Harvard University Library ........... [log in to unmask]
> Cambridge, MA, USA 02138 .............
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|