IMHO, the metadata attached to a document is *not* the place to store
information like Author's contact details. Any attempt to do so, I would
consider a kludge of the highest magnitude - dangerous and misleading.
After all, I might write an article this year while I'm living in Canberra.
Then next year, when I move to Perth, the
"DC.Creator.Address=somewhereincanberra" tag will be useless to anyone trying
to get in contact with me.
There should probably be another library of metadata dealing specifically with
people.
So you have "DC.Creator.Name=Alex Satrapa". You go looking for this in the
global directory (sorry, I'm too lazy to look up a real example right now) for
"Alex Satrapa". I'd suggest you avoid "collected" directories like four11 -
last time I checked they listed four email addresses for me, one of which I've
never had, one which I stopped using about 5 years ago, and none of them are my
current ones. A directory would have to be a *contributed* directory, like the
PGP Public Key service.
IMHO, any "STM" series of metadata tags would be up to that body to describe
and define - just as the "DC" series of tags is being developed by the Dublin
Core community.
Then it's up to Meta-data-search-engines to realise that "keyword <in>
DC.subject" also applies to any "sub-elements" of DC.subject that have been
created by the local metadata cataloguer. (ie: <in> DC.subject would be
interpreted as meaning "appears in DC.subject or any sub-element thereof").
This would eliminate any search/recovery penalty due to highly refined schemas.
This would also add new meaning to the term "refining your search". Instead of
adding more search criteria, a knowledgable user could see the meta data
elements being returned, and focus on particular sub-elements.
Hmm... which brings to mind the idea of using X-space (or some other zoom-able
map) as a means of presenting search results from a meta-data search engine.
Such an engine would return two sets of results - the actual data found, and
the metadata tags associated with that document (highlighting the ones that
were used by your search criteria).
You search for "smithy <in> DC.Subject" and you get 15,000 documents about
jewellery, horse shoes, medieval armour, coke firing, the ACME Anvil
collection, etc. You also get a list of sub-elements available - such as
"DC.Subject.Occupation". Hmm... at which I run out of imagination to continue
my manufactured example :)
But I digress...
Regards,
Alex
[log in to unmask] wrote:
> Thanks for this Stu. I'm not familiar with vCard or the LoC Name Card
> authority (giving the game away that I'm not from a library or information
> science background) - do you have any URLs that I can get to to find out
> more? I'm certainly happy to promote standard ways of describing material.
>
> BTW, is the whole DC.Creator.PersonalName.Address a kludge? This is what I
> thought DC Qualified was likely to suggest for personal addresses. Or would
> STM.Affiliation be a kludge? Or STM.Creator.PersonalName.Affiliation? Are
> they all kludges without defined schemes, or do they vary in kludginess?
>
> Presumably, whatever set we come up with has to allow a degree of
> optionality re granularity too. That is, as a content processor, I would
> want to have the option of defining affiliation as one undifferentiated
> address (e.g. STM.Affiliation = "John Wiley & Sons Ltd, Baffins Lane,
> Chichester, West Sussex PO19 1UD, UK") or differentiated in more detail (e.
> g. identifying name of company, street, town, county, postcode, country).
> We know from the SGMLing of our journal headers that fine granularity comes
> at a cost (in content analysis and tagging) which we would want the option
> of incurring or not, depending on the usual cost-benefit comparisons. This
> is a commercial decision, of course.
>
> Cliff
>
> [log in to unmask] on 15/09/98 12:45:47
>
> Please respond to [log in to unmask]
>
> To: Cliff Morgan/Chichester/Wiley, [log in to unmask]
> cc:
> Subject: Re: Q: target group?
>
> [log in to unmask] wrote, among other things:
>
> > >In STM journals, we are likely to regard an author's affiliation as
> > significant metadata.
> > Dublin Core has specifically stated that affiliation is *not* to be
> > regarded as equivalent to
> > DC.Creator.PersonalName.Address (since this is the author's personal
> > address, not his or her
> > place of work), and suggested that this tag should be dealt with as a
> > local extension. (I am lobbying for an authoritative body such as the
> > International STM
> > group to endorse a set of local extensions optimised for STM journals.)
>
> There is clearly a need for structured affiliation information, contact
> information, and address information associated with agents such as
> Creator, Contributor, Publisher. The 'dot syntax' in the above example is
> a META-tag kludge that will not serve us well in the long run. One current
> discussion in the Data Model group is to adopt an acceptable structure from
> elsewhere and promote its adoption. vCard is one such example, promoted by
> the Internet Mail Consortium as well-structured information about people...
> a virtual business card. Another alternative is the Library of Congress
> Name Authority structure, which has a somewhat different orientation, but
> also represents a structured agent record.
>
> I urge Cliff to look at these options to see whether either meets the
> needs of the STM community and report back to us. If not, an additional
> community-based proposal would certainly be in order.
>
> stu
|