I won't hesitate to offer my opinion (after all, most list subscribers
probably redirect all my mail to /dev/null anyway) ;)
Perhaps those amongst us who desire to store redundant information, such
as the publisher's contact details as they were at the time of
publication of the resource that we're trying to describe, are trying to
write too much into the metadata of a resource. I prefer the minimalist
approach, to allow people to discover resources that are available.
After discovery, the important things like contact details and
affiliations should become apparent from relationships between the
values in fields of the metadata for that resource, or from the content
of the resource itself. DC is supposed to be about resource discovery,
not cataloging contact and affiliation information for various entities
around the globe.
Surely, if I wanted to attribute a resource to a particular company,
wouldn't it be enough to quote their company name and an indication of
their nationality/business registration?
eg:
DC.Contributor = "tSA Consulting Group Pty. Limited, Australia, ACN 006
712 296"
Is there a standard means for identifying a company by its nationality
and registration details? Even this information is likely to be
obsolete, with time.
It's a little harder for human contributors, since we don't all have ID
numbers tattooed to our foreheads or have ID chips under the skin of our
right wrist (yet). Still, it makes no sense to attribute the email
address "[log in to unmask]" with the entity Alex Satrapa,
since said entity hasn't had that email address for almost a decade.
I disagree with the notion of including redundant fields like
DC.Creator.Email, mainly for the reason that not everyone is going to
realise that the metadata, associated with the document I wrote 10 years
ago, contains obsolete information. The only email address, postal
address or other contact information that has any relevance, is whatever
the current versions of those details are.
Affiliation with a sponsor organisation should be apparent from the
DC.Creator and DC.Contributor fields (if not from the actual content of
the resource). After all, the people who paid Dr. X PhD the sum of
$250,000 to write that thesis, are significant contributors, no?
But that's probably topic for another discussion.
Alex
"Gary E. Masters" wrote:
>
> I hesistate to offer an opinion, but this seems to make a point for
> good authority control. The email address could be an attribute of an
> entity that is the creator. My past opinion has been more that
> authority control was nice to have, but I questioned it at times
> considering the work it took.
>
> Any opinions?
>
> Gary Masters
>
> Dan Brickley wrote:
>
> > Here's a slogan for thinking about 1:1 and its relation to the Dublin
> > Core datamodel issues:
> >
> > Don't ascribe properties to an object that are
> > really properties of some other related object.
> >
> > In other words, don't pretend that the email address of the creator of
> > an image is a property of the image. Don't pretend that the fax number
> > of the office of the publisher of a book is a property of that book.
--
Alex Satrapa
tSA Consulting Group Pty Ltd.
Canberra, Australia
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|