 |
 |
But author's affiliations aren't just contact addresses, they're often an indication (the only indication?) of the institutions which were associated with the work which is being reported. As such they are significant to the assessment of whether the document is a "must read" or "could be interesting" or even, for the prejudiced reader, "forget it" - especially when there's a price attached to reading it. So there would be a real loss of information if the link between document and affiliation-at-the-time-of-writing was lost. And if doing anything in document metadata has to wait on the establishment of comprehensive authority systems for person metadata - which must ultimately be the "right" way to do it - it may have to wait quite a long time. Doesn't it come down to ensuring that there's a datestamp attached to the affiliation, or indeed to any address information anywhere in any metadata scheme? David In message <[log in to unmask]>, Alex Satrapa <[log in to unmask]> writes >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 > > > > -- David Martin [log in to unmask] Tel +44 (0)181 892 2272 Fax +44 (0)181 892 9109