Hi there, I heartily agree that this functionality was difficult to get going, and that making it easier would be a good thing.
I have a small concern about the metadata fields that might be employed, though. In my search to figure out how to do it, I ran across a message from someone that suggested using a schema other than DC, so that they wouldn't be harvested via OAI and such. I thought that was a pretty good idea, since the fields would not provide any useful information outside the specific instance. I think that, even if these fields are standardized within DSpace, they still won't provide useful information to the outside world. Just another 2 cents. B-- >>> On 9/9/2010 at 10:08 AM, in message <4c890699.5050...@duraspace.org>, Tim Donohue <tdono...@duraspace.org> wrote: > Hi Richard, > > What I mean by preconfigure is the following: > > (1) Pre-create embargo metadata fields which DSpace will use by default, > and pre-configure them in dspace.cfg as the default settings. (People > can always change these fields as needed -- and although there is no DC > profile/standard for this, DSpace already doesn't fully follow DC > profiles/standards for metadata) > > (2) Based on #1, pre-configure the metadata fields in input-forms.xml > (but comment them out by default). > > The problem to me seems to be that it's a bit too complex and roundabout > to enable embargoes (especially for non-technical users). Currently, > you need to know that there are 3 separate steps (create fields, updated > dspace.cfg, and know how to add the fields properly to input-forms). I > think it'd make it much easier for non-techies if we can simplify to one > step -- just uncomment the fields in input-forms.xml. The techies can > still chose to change the default metadata fields or other settings -- > but, at least we aren't creating as much of a barrier for others. > > It just seems like there's some sort of obvious barrier here -- and I > don't think it's just a documentation problem. A quick search of > 'dspace-tech' archives shows 64 messages with a subject of "embargo" > this year -- most of which are questions about how to enable it and get > it to work right. I've heard similar questions off list as well. > > http://www.mail-archive.com/search?a=1&l=dspace-tech%40lists.sourceforge.net&has > > words=embargo&from=¬words=&subject=&datewithin=1y&date=09%2F09%2F10&order=releva > nce&search=Search > > Just my thoughts... > > - Tim > > On 9/9/2010 10:54 AM, Richard Rodgers wrote: >> Hi Tim: >> >> Just a remark below: >> >> Richard >> On Sep 9, 2010, at 11:29 AM, Tim Donohue wrote: >> >>> I'd actually go one further and say: >>> >>> (1) We should update the manual to make clearer (like Mark suggests) >>> >>> AND >>> >>> (2) We should work to ship 1.7 with a default embargo already setup >>> (i.e. pre-configured) -- so that all you need to do is update >> >> I'm not sure what you mean - it *is* already enabled (i.e, the setter& >> lifter > are functional) >> the only thing you need to do is decide on which metadata fields the terms& > lift will map to. >> Are you saying we want to legislate those? There is no DC profile etc > standard that I'm aware of for >> embargo terms. >> >> Or do you simply mean we should put xml comments in input_forms.xml? Like: >> >> <!-- make sure the terms appear here --> >> >> Can you explain what you mean by pre-configure? >> >>> input-forms.xml and uncomment the pre-configured embargo field(s). If >>> an institution doesn't like the pre-configured version, they can always >>> modify it to use different fields or have different values, etc. >>> >>> What do others think? Should a pre-configured version be in 1.7? >>> >>> It seems like this question keeps popping up over and over again in >>> different forms (e.g. "how do I enable it?", "how does it work?", etc.) >>> Might be best to make this easier for everyone with a pre-configured >>> version -- and let them decide if they want to extend it or not. >>> >>> - Tim >>> >>> On 9/9/2010 10:10 AM, Mark H. Wood wrote: >>>> I worked over the Javadoc in the embargo package, to improve my >>>> understanding and (I hope) to fill in the overall process and >>>> requirements a bit. Committed revision 5342. >>>> >>>> The new package comments might serve as an appropriate starting point for >>>> expanding the manual in this area. >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net Dev2Dev email is sponsored by: >>>> >>>> Show off your parallel programming skills. >>>> Enter the Intel(R) Threading Challenge 2010. >>>> http://p.sf.net/sfu/intel-thread-sfd >>>> >>>> >>>> >>>> _______________________________________________ >>>> DSpace-tech mailing list >>>> DSpace-tech@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>> >>> ------------------------------------------------------------------------------ >>> This SF.net Dev2Dev email is sponsored by: >>> >>> Show off your parallel programming skills. >>> Enter the Intel(R) Threading Challenge 2010. >>> http://p.sf.net/sfu/intel-thread-sfd >>> _______________________________________________ >>> DSpace-tech mailing list >>> DSpace-tech@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech