From: Larry Stone [mailto:l...@mit.edu]
I mostly agree, but suggest you consider what happens when e.g. the LDAP
entry goes away; we can't get rid of the EPerson because it's
connected to
some policy objects or something,
For the most part, I wouldn't consider policy objects to be relevant - if
Hi Gaurav,
welcome!
I like to see this information stored in database so that you have less
concern about write/read lock and a more scalable solution when a hight
number of collections are availables (at the moment we are maintaining a
DSpace repository with more then 1000 collections).
I want
Off the top of my head...
Database rather than xml.
A database table of item types editable via UI eg. Journal article, book , etc.
For each type the administrator would select the appropriate metadata types,
which implies a second database table 'itemtype2metadatatype'. This table could
also
Certainly in the database, but we should also consider the development model
for your work critical to re usage of this functionality in the future 2.0
release of DSpace. To do so you really only have to follow a few important
guidelines in your work that I would recommend target 1.6.0 for the
I have to add an authority control mechanism to DSpace for an
institutional repository, so I'm doing it as modification to the 1.5.2
source in the hope it will get adopted into 1.6.
To begin discussion, I put up a wiki page about the design:
Larry,
I think this would be an interesting project. But I will propose
three points of concern.
1.) Authority Control aligns with Vocabulary Encoding Constraints
found in the the DCMI DescriptionSetProfile
(http://dublincore.org/architecturewiki/DescriptionSetProfile). More
specifically, DCMI
