Hi Mateusz!
You plan the following fields:
* dc.contributor.author_id - id of an author in external system,
* dc.contributor.organization - author's affiliation,
dc.contributor.organization_id - id of an affiliation in
external system,
* dc.identifier.bib_id - id of an Item in external bibliographical
system
Beware that using different properties for multiple "sub-objects" in a
flat model like DSpace brings the problem of synchronization of fields
occurrences during updates (and display).
People are used to papers with little indices after authors names
(affiliations being prefixed by those indices), may be it is a solution
for you?
You could then use the standard DSpace 1.6 Authority control:
* dc.contributor.author controlled by an Authority source (you then
already have a field part for the name (Lucene Indexation) and a part
for the author id.).
You also have a numerical qualifier used today to grade the authority
quality. You could add 1, 2, 3, 4, 5, etc. to this qualifier to indicate
the indice of the linked affiliation.
* dc.contributor.affiliation controlled by an Authority source for
institution. Name will be indexed by Lucene, Id will be stored and you
can add an indice to the "grade", indice refered by affiliated authors.
You will then have to:
1) create Authority Control Plugins for you Authorities (authors and
institutions)
2) extend the Authority Control Classes to extract the indice from the
grade and make it a separate field (whilst not changing the database itself)
3) modify the item display and update to allow modification of the indice
Larry Stone(1) and Andreas Bellini(2) are the authors of this part of
the code...
(1) MIT
(2) CILEA
Have a nice day!
Christophe
Mateusz Neumann a écrit :
> On Thu, 2010-05-06 at 12:04 +0200, Christophe Dupriez wrote:
>
>> Hi again Mateusz!
>>
>
> Bonsoir Christophe
>
>
>> If you want to keep more than current affiliation of the author, I see
>> two possible solutions:
>>
>> 1) You add an intermediate object to keep information about when the
>> author worked at a given institution and with which responsibilities.
>> Such a structure is too heavy to be represented nicely by relations
>> between flat catalographic records (you need a FRBRized library
>> management application).
>> But it can certainly be implemented as an SQL or RDF based addon to
>> DSpace.
>>
>
> That is what we are heading towards. As I have wrote earlier this day,
> we need to have quite sophisticated reporting tool based on
> bibliographical data. We are still investigating the best approach but
> it seems we will end up with a little modified DSpace and another
> bibliographical/reporting system linked by some nice interface.
>
>
>> 2) Using WindMusic like Authority control, you add a reference to the
>> institution next to the author:
>> records can then be searched by authors and by institutions (and by
>> institution containing institutes).
>> For instance, in my coding system, this could be written in
>> dc.contributor.author (or another field of your choice):
>> author_ person_1234 _deceased doctorant_ institute_345
>> Meaning that "John Smith (person #1234) (now deceased) authored the
>> document when he was doctorant in University of XYZ (code 345)"
>> In some catalog or database (DSpace or other) accessible on the web,
>> person "1234" is defined and the user can find there more information
>> about the person.
>> Idem for institutions (University of XYZ).
>>
>
> I think of adding four properties:
> * dc.contributor.author_id - id of an author in external system,
> * dc.contributor.organization - author's affiliation,
> dc.contributor.organization_id - id of an affiliation in
> external system,
> * dc.identifier.bib_id - id of an Item in external bibliographical
> system
>
> Of course there would be possibility to search/browse by Affiliations
> (similarly to "Issue Dates", "Authors", "Titles", "Subjects"). And
> those '*_id' fields will be used in interface with an external
> bibliographical system.
>
>
>> In Lucene (helped with Ajax Autocomplete to select persons or
>> institutions), you can then search using the person name (translated
>> into its code) and/or institutions.
>> You can even restrict further the search using the prefixes (author,
>> doctorant) or the suffixes (deceased).
>>
>
> That is nice. I will think about it.
>
>
>> Codes are indexed but also their translations and all their synonyms.
>>
>> I use this at the Belgium Poison Centre to represent PubMed MeSH
>> indexing (which uses hierarchical "qualifiers" next to each MeSH term).
>>
>> But, I agree with you that an information structure is not a complete
>> application!
>> For a complete existing "Author page" management system, something like
>> what HKU has implemented may be even nearer to your needs.
>>
>> Good luck!
>>
>
> Merci beaucoup!
>
> --
> Mateusz
>
>
>
>> Christophe
>>
>>
>> Mateusz Neumann a écrit :
>>
>>> Bonjour Christophe
>>>
>>> On Thu, 2010-05-06 at 08:52 +0200, Christophe Dupriez wrote:
>>>
>>>
>>>> Dzieńdobry Mateusz!
>>>>
>>>> In the SKOSified world, hierarchies are all around:
>>>> http://www.w3.org/2004/02/skos/
>>>> My proposal for authority control in DSpace is based on the SKOS
>>>> standard design.
>>>>
>>>> DSpace is managing "human targeted" catalogues of simple and "flat"
>>>> objects.
>>>> But, if fields of those objects can contain links (relations with other
>>>> objects) open to human exploration but also to automated management,
>>>> then the DSpace is not flat anymore.
>>>>
>>>> Bibliographic Records can relate to Authors which can relate to
>>>> Institute which can relate to Institutions, etc.
>>>>
>>>>
>>> We have a proverb in Poland "the devil is hidden in details" which means
>>> the real problems begin when you dig deeper. There are several issues
>>> that might be difficult to address using your approach:
>>> * an author might have a few affiliations (for example "University
>>> of Berne" that she/he uses in articles on mathematics and
>>> "University of Zurich" for ones concerning physics)
>>> * an author might change (several times) its affiliation (let us
>>> say for the "Institute for Advanced Study")
>>> still he is the same "Albert Einstein".
>>>
>>> If I understand it right, using DSpace catalogue hierarchy approach, we
>>> would end up having three different Albert Einsteins. Which is
>>> something we must avoid.
>>>
>>>
>>>
>>>> So, I use DSpace to manage objects and I use my SKOS API to manage
>>>> values of objects fields.
>>>> Those values can be an id of an object (a relation).
>>>> Those id being coded as words (SKOSscheme_codeInScheme), Lucene word
>>>> search insures efficient retrieval along links.
>>>> And if the SKOS authority list is coming from a DSpace collection, the
>>>> loop is closed.
>>>>
>>>>
>>> That is quite similar to our plan. We want to make this this "recurent
>>> table" searchable. During indexing a new Item we will look for
>>> additional metadata (configured somewhere) and tell Lucene to take
>>> special care of them. Then in Manakin we plan to display nice
>>> ajax-expandable tree of metadata (for affiliations: University ->
>>> Department -> ...) that would link to specific queries (for example
>>> "((affiliation:Institute for Advanced Study))".
>>>
>>>
>>>
>>>> In WindMusic, you find:
>>>> * The DSpace collections being documents but also Authority list
>>>> (authors, publishers, keywords in hierarchies, collections, orchestras):
>>>> http://www.windmusic.org/dspace/community-list
>>>> * A Mazurka: http://www.windmusic.org/dspace/handle/68502/35027
>>>> * Mazurka as a subject:
>>>> http://www.windmusic.org/dspace/handle/68502/22050?searchname=lorthes_183
>>>> * Mazurka is a musical genre:
>>>> http://www.windmusic.org/dspace/handle/68502/22050?searchname=lorthes_183
>>>> The record can be retrieved by the subject "Mazurka" but also by its
>>>> all its generics "Musical Genre", "Music"
>>>> * The SKOS view of Authors records make their nationality a
>>>> "broadMatch": you can therefore find all records indexed by an author of
>>>> a given nationality
>>>> A search for musicals from a polish author:
>>>> http://www.windmusic.org/dspace/simple-search?query=country%3Acountry_PL
>>>> The same principle can be used to search for all the documents
>>>> written by somebody belonging to a given institute/institution (whatever
>>>> the depth of the hierarchy)
>>>>
>>>>
>>> Well it seems it is quite the same approach we are developing :) That
>>> is assuring to see you have deployed something that similar.
>>>
>>>
>>>
>>>> If your aims are strictly to manage authors and institute, you may also
>>>> ask for Andreas Bellini to explain the work he done with David Palmer at
>>>> Hong Kong University (see below)
>>>>
>>>>
>>> We want to build a solution that would work as basic Institutional
>>> Repository AND would enable to create some nice reports on how much has
>>> someone written in 2009 or how many publications came from Department of
>>> Physics at University of Warsaw in 2010 etc. So it might be somehow
>>> similar to what Andreas Bellini has achieved. Thanks for forwarding his
>>> email.
>>>
>>> Salut!
>>>
>>> --
>>> Mateusz
>>>
>>>
>>>
>>>
>>>> Cześć !
>>>>
>>>> Christophe
>>>>
>>>> Message to the DSpace General list in december 18th 2009:
>>>>
>>>> The University of Hong Kong wishes to announce HKU ResearcherPages for
>>>> each of its many authors, now appearing in the The HKU Scholars Hub, the
>>>> institutional repository of HKU. Three examples,
>>>>
>>>> http://hub.hku.hk/rp/rp00023 Prof Samaranayake, Dean of Dentistry
>>>>
>>>> http://hub.hku.hk/rp/rp00056 Prof Bacon-Shone, Associate Dean of
>>>> Social Sciences
>>>>
>>>> http://hub.hku.hk/rp/rp00060 Prof Tam, Pro-Vice Chancellor
>>>> (Research)
>>>>
>>>>
>>>>
>>>> This work is the result of a successful collaboration between HKU and
>>>> CILEA (AePIC Team). Much of the code developed for this project has
>>>> been included in the forthcoming version 1.6 of DSpace, which will soon
>>>> be released to the community.
>>>>
>>>> http://www.cilea.it/
>>>>
>>>>
>>>>
>>>> Highlights:
>>>>
>>>>
>>>>
>>>> * Author-centric bibliometrics from Scopus – the results of an on-going
>>>> massive bibliometric rectification project, between Elsevier and HKU.
>>>> [Pls note the +/- expand/collapse box for bibliometrics in pages
>>>> above]. This is in preparation for our annual Performance Reviews, and
>>>> our impending Research Assessment Exercise.
>>>>
>>>>
>>>>
>>>> * Author-centric bibliometrics from ResearcherID.com (Web of Science) –
>>>> the results of an on-going large scale institutional upload of
>>>> publication lists for each HKU author to RID. One example,
>>>>
>>>> http://www.researcherid.com/rid/C-4405-2009
>>>>
>>>>
>>>>
>>>> * Unique identifier for each HKU researcher. In URLs above, “rp00023”,
>>>> “rp00056”, and “rp00060” are examples of this.
>>>>
>>>>
>>>>
>>>> * Integration with HKU’s Media Directory, to show subjects on which each
>>>> researcher can speak to, or write for the media, and in which
>>>> languages. The Hub is now an expert finder, for those in gov’t &
>>>> industry wishing to find specialists for consultancies, contract
>>>> research, etc. Pls note facets by which RPs can be retrieved,
>>>>
>>>> http://hub.hku.hk/rp/search.htm
>>>>
>>>>
>>>>
>>>> * Authority control; disambiguation of like named individuals, linkage
>>>> from variant names to the established heading, synonymy between
>>>> established headings in different vernacular scripts. Examples,
>>>>
>>>> http://hub.hku.hk/browse?type=author&order=ASC&rpp=100&starts_with=tam+p
>>>>
>>>> http://hub.hku.hk/browse?type=author&order=ASC&rpp=100&starts_with=%E8%AD%9A%E5%AE%B6%E9%9B%AF
>>>>
>>>>
>>>>
>>>> * Article level metrics from Scopus, Web of Science, and Google
>>>> Scholar. In example below, pls scroll down to red buttons,
>>>>
>>>> http://hub.hku.hk/handle/123456789/43518
>>>>
>>>>
>>>>
>>>> Further description:
>>>>
>>>>
>>>>
>>>> * Presentation given at the Dec 2-4 Digital Repository Federation
>>>> International Conference (DRFIC 2009), Tokyo:
>>>>
>>>> http://hub.hku.hk/handle/123456789/56562
>>>>
>>>> * Presentation given at the Nov 18-20 Pacific Rim Digital Library
>>>> Association (PRDLA 2009), Auckland:
>>>>
>>>> http://prdla.ucmercedlibrary.info/?s=critical
>>>>
>>>> * Thomson Reuter’s Customer Profile and Case Study
>>>>
>>>> http://wokinfo.com/benefits/testimonials/palmer/
>>>>
>>>> * Thomson Reuters’ “Intelligent Information for Life” article
>>>>
>>>> http://intelligentinformationforlife.com/palmer/
>>>>
>>>> * HKU press release
>>>>
>>>> http://www.hku.hk/press/news_detail_6081.html
>>>>
>>>>
>>>>
>>>> The next round of development begins soon.
>>>>
>>>>
>>>>
>>>> David Palmer
>>>>
>>>> Systems Librarian
>>>>
>>>> Technical Services Support Team Leader
>>>>
>>>> Scholarly Communications Unit Head
>>>>
>>>> The University of Hong Kong Libraries
>>>>
>>>> Pokfulam Road
>>>>
>>>> Hong Kong
>>>>
>>>> tel. +852 2859 7004
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mateusz Neumann a écrit :
>>>>
>>>>
>>>>> Bonjour Christophe
>>>>>
>>>>> On Tue, 2010-05-04 at 23:52 +0200, Christophe Dupriez wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Dobry Wieczór Mateusz!
>>>>>>
>>>>>> You may want to look at the WindMusic presentation in Göteborg.
>>>>>> http://gupea.ub.gu.se/dspace/handle/2077/21341
>>>>>> http://www.windmusic.org
>>>>>>
>>>>>> In WindMusic, Authors are stored in a DSpace collection (so they are
>>>>>> managed with the regular DSpace UI)
>>>>>> And they are used for search and update as an authority control list.
>>>>>>
>>>>>> Dynamic SQL source allows to access dynamically different source (with
>>>>>> strong caching) to use any accessible database as an authority source.
>>>>>>
>>>>>> Multiple authorities for a field are supported (and the option of "free"
>>>>>> uncontroled content): it is often necessary to "chain" authorities so an
>>>>>> Author (a Subject, a Journal...) can be in a local application, in the
>>>>>> institution repository or in an external repository;
>>>>>> Each authority source with its independant access method...
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks a lot for sharing the ideas. It is a big pleasure to see
>>>>> something working :) But I think your solution would not be enough for
>>>>> our sophisticated demands. I think I would rather stay on the path we
>>>>> have already been thinking of, maybe "widening" it a little bit as Mark
>>>>> Diggory has suggested.
>>>>>
>>>>> There would be a new "recurrent table" (where records can point to
>>>>> another "parent" records in this table, enabling creation of tree-like
>>>>> structure). Records of this table would define affiliations structure
>>>>> (University -> Department -> Institute -> ...). An Item (or an Entity
>>>>> in general, as Mark has suggested) would point to that table defining
>>>>> for example author's affiliation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
