[Dspace-tech] Replacing handles with other identifier
I'm a relative newbie at DSpace, but I've been asked to look into replacing handles with a different persistent identifier for our installation (still in the planning stages). From what I've read on the archive, this is a somewhat difficult problem, as there are supposedly dependencies scattered throughout the code on the syntax of a handle. From a quick study of the code, I can't find any dependencies (beyond expecting a URI) outside of HandleManager.java. If this is true, we could use a different identifier by rewriting HandleManager.java -- not a tiny task, but at least a localized one. It's a bit unclean; HandleManager.java has to be rewritten rather than overridden because it uses static methods. I'd suggest that a future implementation of DSpace should change HandleManager so that an instance is created factory-style. The instance could then be a subclass, depending on a configuration setting. All references to HandleManager would have to be changed to call the instance rather than the static method, so this would be a somewhat disruptive change, but not one that would cause major coding difficulties. Am I on the right track here, or are there other issues which I've missed? -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Replacing handles with other identifier
Richard Jones wrote: > Hi Gary, > > Which alternative identifier system were you planning on? We'd be using Harvard's Name Resolution Service (NRS) URN's, which is used for our Digital Repository Service and E-Resources. > For DSpace 1.6, we have rewritten a lot of the code for handling > identifiers, and thus adding new schemes is much much more > straightforward. I'm about to go on holiday, but when I get back I'd be > really interested in talking more with you about what you want to do. > In the mean time, please feel free to take a look at the trunk in > sourceforge. Thanks! -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Persistent identifiers, again
As some of you may recall, I've been looking into implementing a non-Handle approach to persistent identifiers in our local version of DSpace. My approach has been to replace HandleManager bodily. So far I've gotten it to the point where it has the same functionality as out-of-the-box DSpace; that is, the handles don't work when accessed as external identifiers, but a manual substitution of the URL base produces a working URL. Each time I blow away DSpace (as often happens during early stages of code development), I've noticed that the ID's start over from 1. It looks to me as if the HandleManager doesn't provide a strong guarantee of uniqueness; if DSpace is totally reinitialized, old Handles may be recycled. If this happened in a production environment, Handles for obsolete objects could point to the wrong object, rather than failing to resolve as they should. This makes me think that for our environment, which stresses the "unique" in URN's, I need to add a stronger guarantee of uniqueness. It also seems like a minor bug in DSpace. Have I missed anything? Does something come into play when a live handle server is used, which provides a stronger guarantee of uniqueness? I'm aware, by the way, that DSpace 1.6 has totally new code for non-Handle persistent identifiers. Our schedule doesn't let us wait. Don't blame me, I'm only the programmer. :) -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Adding a jar to a DSpace 1.5 project
It's embarrassing that I should have to ask how to make a simple change to a makefile, but I'm finding Maven to be one of the most bewildering, overly complex pieces of software I've run into. I've added some Java code within dspace-api, in our own package. Maven sees that, with no problem, and tries to compile it. But for it to compile successfully, it needs to use a couple of .jar files which we have previously developed here. I've put the jars into (dspace/target/dspace-1.5.0-build.dir/lib/), but that's not enough to get them picked up. I'm guessing that I have to add tags to pom.xml, but can't find any documentation which I can comprehend. The pom reference page (http://maven.apache.org/pom.html) talks about the groupId and artifactId, but neither one of these seems to be the name or path of the jar file. The packaging tag tells Maven that it _is_ a jar file, but apparently nothing more specific than that. Could someone point me at a simple explanation of how to get this to work? -- Gary McGath Digital Library Software Engineer Harvard University Libraries, Office for Information Systems - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Adding a jar to a DSpace 1.5 project
Mark Diggory wrote: > > On Apr 16, 2008, at 12:11 PM, Gary McGath wrote: > >> It's embarrassing that I should have to ask how to make a simple change >> to a makefile, but I'm finding Maven to be one of the most bewildering, >> overly complex pieces of software I've run into. > > > Well, it is different than most "Make" or "Ant" tools out there because > it is both a build tool and a distribution management tool, much like > Yum/RPM, Gentoo/Emerge, Perl/CPAN, or R/CRAN. If you can wrap your > head around that, it will save you some frustration. It is just a > different model. > >> I've added some Java code within dspace-api, in our own package. > > > We've moved away from suggesting that you add code to dspace-api or > alter code there, this is one of the reasons we aopted MAven, was to > modularize the codebase and free the end user from having to alter this > code directly and worry about "merging changes" all the time. > >> Maven sees that, with no problem, and tries to compile it. But for it to >> compile successfully, it needs to use a couple of .jar files which we >> have previously developed here. > > > Tell me a little about those tools you've developed? How are they > managed, is there a release cycle... I can direct you on how to install > them into Maven and adjust the build dependencies so they are included. The starting point of what I'm doing is replacing HandleManager.java in place with our own code -- ugly but necessary, since it consists entirely of static methods. To make it generate real persistent identifiers, it's necessary to add a couple of supporting classes, which I've put in an edu.harvard.hul.ois package, and these in turn require some jar files. Should I be creating a new subproject for this code (other than HandleManager)? Thanks for any help you can offer. -- Gary McGath Digital Library Software Engineer Harvard University Libraries, Office for Information Systems - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Adding a jar to a DSpace 1.5 project
Mark Diggory wrote: > > On Apr 16, 2008, at 1:03 PM, Gary McGath wrote: > >> Mark Diggory wrote: > > >>> Tell me a little about those tools you've developed? How are they >>> managed, is there a release cycle... I can direct you on how to >>> install >>> them into Maven and adjust the build dependencies so they are >>> included. >> >> >> The starting point of what I'm doing is replacing HandleManager.java in >> place with our own code -- ugly but necessary, since it consists >> entirely of static methods. To make it generate real persistent >> identifiers, it's necessary to add a couple of supporting classes, which >> I've put in an edu.harvard.hul.ois package, and these in turn require >> some jar files. > > > Sounds like your trying to use the Harvard Naming Service? Can you give > me a list of the jars you require? Are any of them third party to OIS? The files are nrs.jar and jdbc.jar, both local to OIS. The Java files so far are called URNMaker.java and URNException.java. The jar files set up a thin JDBC wrapper for talking to our Name Resolution Service database. It's not a huge amount of code. There are a few extra items in the config file to set up the database connection. We have the jars set up in a local repository (Unix directory), with some simple version management. The repository isn't mounted on the machine we're using for DSpace work and isn't available by HTTP, so Maven's proclivity for fetching resources from repositories might be difficult to satisfy. > Its a tough call, we are currently rewriting the whole Handle/ > Identifier mechanism (as we discussed earlier). In this case there may > be a mix of approaches, It might just be better to alter dspace- api > (HandleManager) then port over to the new Identifier service when it > comes out in the next major release (but that may very well be next > year). Which would mean that you'd need to port over your changes to > dspace-api on every minor release. > > But if you do, it would save you work later if you encapsulate all your > hul.ois identifier stuff in a separate addon project. This project > would be added as a modules to [dspace-source]/dspace/pom.xml and added > as a dependency in that pom (for CLI applications) and in > [dspace-source]/dspace/modules/pom.xml (for webapplications) > > tell me a little more about all the added dependencies and I'll try to > map out the strategy in that context. -- Gary McGath Digital Library Software Engineer Harvard University Libraries, Office for Information Systems - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Adding a jar to a DSpace 1.5 project
I've managed to get it to compile without errors as a new subproject; many thanks! Distributing the jars in a local maven repository is a bit more than I want to deal with right now. Mark Diggory wrote: > A slight tangent... does OIS consider these jars to be private > resources, or do they consider at all sharing them with a larger > community at Harvard? Maybe theres an option for distributing them in > a local maven repository of their own? > >> We have the jars set up in a local repository (Unix directory), with >> some simple version management. The repository isn't mounted on the >> machine we're using for DSpace work and isn't available by HTTP, so >> Maven's proclivity for fetching resources from repositories might be >> difficult to satisfy. > > > I doubt it'd be in the same format anyways. Are you working on > deploying just one server, or do you expect this to be What I would > recommend > > so, if you wanted to build against these dependencies "right now" yo > would do: > > mvn install:install-file -Dfile=location/of/jdbc.jar - > DgroupId=edu.harvard.hul.ois -DartifactId=ois-jdbc -Dversion=X.X.X - > Dpackaging=jar > mvn install:install-file -Dfile=location/of/nrs.jar - > DgroupId=edu.harvard.hul.ois -DartifactId=ois-nrs -Dversion=X.X.X - > Dpackaging=jar > > where X.X.X is the version you wish to be using (you can make that up > if you like or use whatever is already there. then in you pom... first > pass I'd say just do it in dspace-api/pom.xml (later we may create > another maven project if it benefits you). > > > ois-jdbc > edu.harvard.hul.ois > X.X.X > > > > ois-nrs > edu.harvard.hul.ois > X.X.X > > > You'll need to do this again on any server (or user) your running > another maven repository in (thus the benefit of deploying instead to a > locally maintained maven repository) which would be added to as a > in the pom and thus the jars could be gotten from on any > account/server you were building on. If you reach this point, it > definitely benefits you to consider having a separate maven project for > the nrs HandleManager adapter that preserves this customization > independent of the dspace codebase. -- Gary McGath Digital Library Software Engineer Harvard University Libraries, Office for Information Systems - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Embargo on DSpace 1.5
Has anyone managed to adapt Jose Blanco's embargo fix (http://wiki.dspace.org/index.php/Embargo_on_Bitstream_v2_%28JSP%29) to DSpace 1.5? I'm starting to go through it, since some form of embargo is among our requirements; some directories have moved, which isn't too bad, but there may more subtle issues, and something for the XMLUI paralleling the JSP appears to be needed. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Including a handle for the German national, > library
> Date: Fri, 25 Apr 2008 12:38:39 +0200 > From: Robert Roggenbuck <[EMAIL PROTECTED]> > Subject: [Dspace-tech] Including a handle for the German national > library > > Hi all, > > recently we decided to set up our OA-Repository using DSpace. > Now I have a question regarding special German circumstances: Is it > possible to replace the "CNRI Handle"-mechanism by a "DNB-URN"? We have been working on a similar issue here. I assume you mean that you want a permanent link to the Deutsche Bibliothek's own naming repository rather than using handle.net? We have been able to do that by making changes in DSpace 1.5 to HandleManager.java and writing some custom code to interface to our own naming repository. It's a bit ugly, but not as bad as some people have made it out to be. I could send you a copy of what we have done if you are interested. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Embargo on DSpace 1.5
Elliot Metsger <[EMAIL PROTECTED]> wrote: > Depending on your timeline for embargo implementation, you may want to take > a look at http://wiki.dspace.org/index.php/User:Emetsger:Embargo . Its an > embargo implementation I'm working on, and hopefully porting to 1.5 this > summer... additional eyes/coding/feedback appreciated. Elliot, I've been aware of your work for some time. Unfortunately, we're on a very tight schedule here. I've found that a significant amount of new work is needed to implement embargo in Manakin, and just figuring out where the hooks should go is the trickiest part. Right now I'm concentrating on the post-processing classes for the steps, which are in org.dspace.submit.step under dspace-api. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Item submission details in Manakin
I previously asked about general information on finding one's way around Manakin, without success. Taking that to mean that there aren't any overall road maps available, I'll recast my question in terms of what I'm trying to do. I am attempting to implement an embargo feature on the XMLUI side of DSpace 1.5. For this, I'm making some use of "Embargo V2" (http://wiki.dspace.org/index.php/Embargo_on_Bitstream_v2_%28JSP%29), but that's oriented toward the JSP user interface, so a lot has to be re-invented. I've figured out large parts of it, and even added Oracle SQL to that page, but need some help on the remaining bits. I've added an embargo date to the license page. My code subclasses dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/submission/submit/LicenseStep.java to put the embargo date field into the page, and dspace-api/src/main/java/org/dspace/submit/step/LicenseStep.java to process the embargo date. This ultimately needs to add the ID of the created item to the "umrestricted" table which is defined by Embargo V2, and put the embargo date into the "date.available" metadata for the item. This can only be done at the conclusion of creating the item (or so I assume), but I'm having an oddly hard time figuring out where that final step is done. Can someone give me a pointer on that? -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace-tech Digest, Vol 26, Issue 42
Sorry about the in-house cross-talk, but this one is under control. For some reason we're still working on, the database for the malfunctioning instance didn't have the views COMMUNITY2ITEM and DCVALUE, which it was supposed to have. This is, we're assuming, an error in the database creation process and not any kind of DSpace bug. Flemion Shafeeq <[EMAIL PROTECTED]> wrote: >>>We have customised dspace in our development machine and tried to run the >>application on a different box, trying some kind of production environment >>here. >>Here the browse functionality particularly for the Authors and the Subject >>link is not retrieving any items submitted to the community/collection we >>have set up. >>The browse links such as "By issue date" and "titles" does returns the >>item in the collection/community. >>The entire browse functionality is working fine in our development server. >>Checked all configurations in the second machine, but its more or less >>the same. >>Tried re-indexing the production server, by following steps on wiki. But >>the script index-all mentioned is absent on [dspace]/bin, Instead there are >>2 scripts in the name of index-init and index-update >>Tried running each of them but its throwing the following error -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] DatabaseManager question
Sigh ... Implemnting embargo on the Manakin side of DSpace 1.5 is
proving to be the bane of my life. I appreciate the suggestions I've
received, but most of them require waiting, and that isn't an option.
Anyway, I've been trying to implement a variant of Embargo v2
(http://wiki.dspace.org/index.php/Embargo_on_Bitstream_v2_%28JSP%29),
and making some progress. It comes down to a modification to
dspace-api/src/main/java/org/dspace/content/InstallItem.java , where I
add the following code to installItem:
DCValue[] dateAvailable = item.getDC("date", "available", Item.ANY);
if (dateAvailable.length > 0)
{
DCValue dcDate = dateAvailable[0];
String dateStr = dcDate.value;
// Convert -mm-dd to Date object
int hyph1 = dateStr.indexOf ('-');
int hyph2 = dateStr.indexOf ('-', hyph1 + 1);
if (hyph1 > 0 && hyph2 > hyph1) {
int year = 2000, month = 1, day = 1;
try {
year = Integer.parseInt
(dateStr.substring (0, hyph1 ));
month = Integer.parseInt
(dateStr.substring (hyph1 + 1, hyph2 ));
day = Integer.parseInt
(dateStr.substring (hyph2 + 1));
}
catch (Exception e) {}
Calendar cal = Calendar.getInstance ();
cal.set (year, month, day);
//item.addDC("date", "available", null, now.toString());
TableRow row = DatabaseManager.create (c, "umrestricted");
row.setColumn ("item_id", item.getID());
row.setColumn ("release_date", cal.getTime());
int n = DatabaseManager.update(c, row);
}
}
What I'm finding is that the row is created, but the item_id and
release_date fields are null. I can add rows with non-null values using
a desktop database client. I've put debugging code into
TableRow.setColumn(String, Date), so I know that it's being reached, has
correct data, and appears to complete correctly. I've stripped out the
debugging code for readability, but it shows that DatabaseManager.update
() is returning 0; i.e., it thinks that the row hasn't been modified in
spite of my setColumn calls.
Obviously I'm doing something wrong, but can't figure out what. Any
suggestions on what I might try?
--
Gary McGath
Digital Library Software Engineer
Harvard University Libraries, Office for Information Systems
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DatabaseManager question
Gary McGath wrote: > Sigh ... Implemnting embargo on the Manakin side of DSpace 1.5 is > proving to be the bane of my life. I appreciate the suggestions I've > received, but most of them require waiting, and that isn't an option. > > Anyway, I've been trying to implement a variant of Embargo v2 > (http://wiki.dspace.org/index.php/Embargo_on_Bitstream_v2_%28JSP%29), > and making some progress. It comes down to a modification to > dspace-api/src/main/java/org/dspace/content/InstallItem.java , where I > add the following code to installItem: I've found the problem, or at least a major part of it. In the Wiki, I'd provided Oracle code to set the primary key with a trigger, since the DEFAULT clause isn't legal under Oracle. But this was conflicting with DSpace's wrapper classes, with the result that the primary key was apparently being set twice. This meant that the UPDATE statement generated by DatabaseManager.java used a primary key value that didn't belong to the row it was trying to update. I altered my database to remove the trigger, and now at least rows are appearing in the UMRESTRICTED table which have actual data. I'm wondering if the DEFAULT clause should be there at all, even for Postgresql. I'm far from an SQL expert, so my conclusions should be treated with caution. I've updated the wiki page (http://wiki.dspace.org/index.php/Embargo_on_Bitstream_v2_%28JSP%29#Create_Database_Tables) to delete the offending trigger, so that now the Oracle code looks just like the old SQL except for the absence of a DEFAULT clause. If there are further issues with this, I'll post again to the list. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Achieving security by obscurity
In order to prevent provenance metadata from being easily reached by users, and to make embargoing watertight, I'd like to disable the "metadata" URLs in Manakin. (I've disabled METS output in the OAI provider for the same reason.) Since they're useful for debugging purposes, it would be nice to have them available, so changing the path component from "metadata" to something else seems like a useful approach. To this end, I edited (dspace-xmlui/dspace-xmlui-webapp/src/main/webapp/sitemap.xmap) and changed the relevant map:match element. When I restarted DSpace, though, it hung. Changing it back let DSpace run normally. Is there something else that needs to be changed in order to disable or modify the metadata URLs? -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Achieving security by obscurity
Mark Diggory wrote: > Likewise I've not been very concerned about its exposure (albeit the > submitters email address embedded there) Ideally this user info in > the provenence metadata should contain obviscated email addresses > like the kind that are allowed as sha signatures in FOAF persons. > Attaching that signature as metadata to the eperson and allowing > lookup via sha signatures would allow the admins to get back to the > user that submitted or approved the item from the metadata. and thus > there would be no need to hide the actual metadata fields from the > public. Whatever the ideal may be, the reality is that there are e-mail addresses in the provenance data. I consider it the basic responsibility of any web application not to publish people's e-mail addresses without their consent. The second problem, peculiar to us because of the embargo requirement, is the inclusion of the bitstream file names, which make it easy to access embargoed files. On both counts, the exposure of provenance metadata is a serious problem and can't wait for 1.5.1. > The "metadata/" space is currently being used as a "catch-all" for > exposing various types of metadata to the user (at least in my > usage), it shouldn't be difficult to block it behind either > authentication or drop it entirely using the sitemap.xmap > configuration of Cocoon in the dspace/modules/xmlui/src/main/webapp/ > sitemap.xmap. You'll need to obtain a copy from the dspace-xmlui- > webapp/src/main/webap/sitemap.xmap. As I said in my post, that was what I did. My first attempt was to change "metadata" to some other string of letters (let's say "detamata"). If I do that, Manakin hangs. I then refined the attempt to redirect "metadata/**" to something else. Same result. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Achieving security by obscurity
Scott Phillips wrote: > We wanted to expose dspace's metadata in a way that can be used by > other applications. They are nice restfull urls that are actionable > and easily predictable. There are a few themes that will do client > side parsing of those urls in javascript, it opens the possibility for > other things to be created. That's not a big argument for handles over > internal identifiers, remember manakin is several years in the making > and during the most of the design cycle dspace's independence from > handles was nothing but a pipedream with no one really working on it. > > As a side note about the protection of Metadata. The DSpace API's data > model says that all metadata for any item (withdrawn or in progress) > is visible to any anonymous user. In general the dspace model is all > objects are visible, but may not be actionable or some parts may be > restricted. In my opinion the API should return an authorization > errors for attempting to access metadata on restricted items, and then > perhaps we could set some kid of security permissions on metadata > fields either in the registry or through some dspace.cfg parameter. > Although the xslt on the pipelie is a pretty easy hack that solves > your problem and is way easier to implement This still leaves the problem of other ways the metadata can be viewed. For instance, we've disabled METS data from the OAI provider because of the same problem. I'm considering patching InstallItem.java so that it never puts the provenance element into the metadata in the first place. Would this cause any problems? -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
