This is an example of what we are trying to attain in the new DSpace Storage Entity model. The point to clarify is that once you start talking about "affiliations, your talking about a three way relationship between the author, the organization and the item. The planned work around DSpace Storage Entities would be capable of defining in your data:
<item-x> ns:author <author-y> <item-x> ns:organization <organization-z> <author-y> ns:firstName "Albert" <author-y> ns:lastName "Einstein" <author-y> ns:affiliation <organization-z> <organization-z> ns:name "Institute of Geometry; Department of Mathematics; University of Zurich" where <item-x>, <author-y> and <organization-z> are all resolvable identifiers discoverable in some system. The important here to recognize, the attributes are not on the Item, but on the Entities related to the Item. Your Affiliations project is just a facet of a larger problem we are seeking to solve in DSpace by relaxing the Data model and allowing more relationships to be expressed in the application. I would also add that the work done on Authority controls also shows an similar means of mapping, in that these Entities that are related to may not actually exist in the repository, but in a metadata registry or naming service external to the repository. So I would look at the Authority Control work to understand that what your suggesting may actually be better off utilizing something external for the moment (for instance HIVE or the like) managing this type of composite metadata within it. I highly commend you for presenting your ideas in the list here. Likewise, I recommend that if your going to start a development project that is addressing how to capture structural relationships in the content like this, that you bring your work forward more into the community to assure its alignment with the current roadmap for DSpace development. We invite developers in the community to utilize the DSpace SVN repository as a tool to manage your local prototype development projects in a transparent manner that allows for collaboration with other community members. You may find others currently working on similar problems and achieve a greater and faster solution by collaborating with them. I know at the moment that Graham Triggs has been working on a 1.x prototype that may have some of the changes your interested in exploring. Mark p.s. I caution to avoid assigning "dc:" to things that are not... "author" is not dublin core, it is a DSpace'ism. On Fri, Apr 30, 2010 at 12:04 PM, Mateusz Neumann <[email protected]>wrote: > On Fri, 2010-04-30 at 14:31 -0400, Peter Dietz wrote: > > It looks like to store author affiliations, you can use dc:contributor > > http://dublincore.org/documents/dc-citation-guidelines/ > > > > > > Then to make that browseable/searchable, it gets added to the index > > (configurable). And to have the affiliation (dc.contributor) show up > > in the item view page, you have a theme which overrides the default > > fields displayed. > > Thanks for the tip. I would definitely try configuring the indexing > process. > > > Also, can you tell more about what the affiliation tree is, perhaps > > I'm misunderstanding what you're asking. > > I was thinking affiliation would be where you have an author "Albert > > Einstein" and is affiliated with two universities, i.e. > > dc:author = Albert Einstein > > dc:contributor = University of Zurich > > dc:contributor = University of Berne > > I was wondering if explaining the problem in details would not be > considered as 'spam'. But since you are asking... :) > > So what I need is system that would be able to: > * Store information on all authors. Usually a book or an article > has more than just one autor. > * Store affiliations per author (nor per Item). Books/articles > happen to be written by people from different universities or > institutions. > * Store "affiliations tree". Let's say Albert Einstein was > affiliated at University of Zurich but he might have been staff > at Department of Physics. So I would like to store both of them > "University of Zurich" and "Department of Physics; University of > Zurich" > > I was thinking of adding a table in database that would store the > information on affiliations structure: > - University of Zurich > | > +-- Department of Physics > | > +-- Department of Mathematics > | | > | +-- Institute of Statistics > | | > | +-- Institute of Geometry > | > +-- Department of Biology > | > +-- Institute of Biochemistry > > - University of Berne > | > +-- Department of Chemistry > | > +-- ... > > - ... > > What I thought of was extending standard Dublin Core fields according to > this schema. A book written by Albert Einstein from Institute of > Geometry at University of Zurich and Joe Doe from Department of > Chemistry at University of Berne would have standard dc fields: > > * dc:author = Albert Einstein > * dc:contributor = Institute of Geometry; Department of > Mathematics; University of Zurich > * dc:contributor = Department of Mathematics; University of Zurich > * dc:contributor = University of Zurich > * dc:author = Joe Doe > * dc:contributor = Department of Chemistry; University of Berne > * dc:contributor = University of Berne > * > ... but additionally some extended: > > * dc:author:1 = Albert Einstein > * dc:contributor:1 = ID_7283 > * dc:contributor:1 = Institute of Geometry; Department of > Mathematics; University of Zurich > * dc:contributor:1 = Department of Mathematics; University of > Zurich > * dc:contributor:1 = University of Zurich > * dc:author:2 = Joe Doe > * dc:contributor:2 = ID_2978 > * dc:contributor:2 = Department of Chemistry; University of Berne > * dc:contributor:2 = University of Berne > * > > what do you think? > > -- > Mateusz > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
