On Fri, 2010-04-30 at 17:00 -0700, Mark Diggory wrote: > 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.
But you still keep the "basic" DC fields for OAI-PMH support for example. Right? Those extended metadata attached to an Entity (an Item, a E-Person, virtually anything, as I understand it) are distinct from the "DSpace/OAI/DC core"? > 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. I will try to think about something more general than just "my" affiliations. If anything comes on my mind, I will surely let you know. > 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. What is the good practice of working with SVN? Since I do not want to apply any patches to main development tree (trunk), should I start a new branch (let us say "dspace-metatree") basing on current trunk (svn copy)? What is the best practice in such cases? > p.s. I caution to avoid assigning "dc:" to things that are not... > "author" is not dublin core, it is a DSpace'ism. thanks :) -- Mateusz > 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 >
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
