Re: [Dspace-tech] Dspace metadata field label not displaying in item displaying
Hi, seems as if you're still using the old 1.3 or maybe a customized version of [dspace]/config/language-packs/Messages.properties file in the default 1.4 Messages.properties files these tags are present. Claudia Hi Community, I once posted this error, but because of the size of the screenshot embedded in the document, the email exceeded the size limit. I did an upgrade from DSpace 1.3 to 1.4. Everything is working fine except displaying the metadata field labels in the item display. The metadata field values are being displayed. I am not sure where I messed up. Attached is a screenshot of what is been displayed. Kind Regards, Admire Mutsikiwa (Mr) ICT Projects Manager Library IT University of Zimbabwe Tell:+263-4-303276 Cell:+263-92239187 Alt/email:[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] ant fresh_install problem on windows xp
Dear All, I have installed all supporting softwares, but at the time of command ant fresh_install result is BUILD FAILED C:\dspace\build.xml:293: Java returned: 1 please give solution for this. Thanks Regards Venkat Narayana Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Reusing bitstream sequence number
Hi Mark: Let me explain the problem more fully, which is a very simple 'inconvenient truth' about assets: some complex digital objects we we want to submit as one Item have filename duplications. E.g. in directory 'q4' we have 'report.doc', but the same filename in directory 'fy08' with different content. In the face of this, we can: (1) reject the content (duplicate filenames detected! - please correct or resubmit as multiple items), which is unacceptable. (2) accept the content, but transform or rewrite into unique filenames (q4-report.doc? report[2].doc?, etc?), which is almost as bad, since we now have both obscured the original name, and altered what we are supposed to be preserving. or (3) [what DSpace currently does] store the filename as *metadata*, which, like file size, can be valuable, but which may not be unique, and use a different identification system that *guarantees* uniqueness within the item (sequence id). I think because it's a number, the sequence ID is easily confused with a version, which it is not. And in fact, there is nothing sacred about sequence numbers as a technique either: we also considered MD5 checksums, timestamps, (maybe now uuids, etc); sequence numbers won because the URLs were shorter and easier to use. The choice of ID schemes does have consequences, as some of John P.'s use-cases illustrate: a 'slot number' (which can be reassigned) is different from a 'sequence number' (which can't), and we can debate the comparative merits of each (or others): my point was that filename is an apparent non-starter (for reasons above). As to the 'heuristic' URLs in 1.5 Manakin, I regard them as closer to a bug than a solution. Just as we would never use an online bank that looked up our account files by taking the first match for our last names, so I think we should not accept indeterminate semantics in bitstream retrieval (I wanted 'fy08', but got 'q4') - that's what unique IDs are for. My 2 cents, Richard Mark Diggory wrote: On Aug 15, 2008, at 12:15 PM, John Preston wrote: On Fri, Aug 15, 2008 at 1:40 PM, Richard Rodgers [EMAIL PROTECTED] wrote: On Fri, 2008-08-15 at 10:12 -0700, Mark Diggory wrote: On Aug 15, 2008, at 9:36 AM, John Preston wrote: Hi. Can anyone say how I can re-use a bitstream sequence number. The use case is the following On Aug 15, 2008, at 10:01 AM, Mark H. Wood wrote: Allowed or not, this sounds risky. If you are overloading the sequence number with a new meaning, this practice is likely to bite you again and again, since the developing stock code won't recognize your second meaning and will take no pains to preserve it Mark is correct about overloading the semantics here. Note, We adjusted the behavior behind the dspace 1.5 XMLUI (but not the JSPUI) to allow for unsequenced name resolution of the bitstreams. For instance: ... It certainly would have been much easier to key Bitstreams on the name rather than a sequence id in the original architecture. I've seen requests such as yours numerous times during my history of working on DSpace and being able to reference resources by simple assignable predictable names rather than internally generated sequence ids makes life on the outside of DSpace easier and 3rd party tooling more powerful. This is something I hope to take into the 2.0 development initiative. Easier perhaps, but unfortunately the Bitstream filename need not be unique, so is a problematic candidate for a durable reference. Richard, that is the crux of my criticism. It would be easier and more useful all around if the name were part of the identifier/re- visioning strategy for the item in DSpace 2.0 using the name as the identifier for the bitstream within the scope of that Item and its item wide revision id, the current XMLUI support is a transition somewhere between the original DSpace behavior and this Item re- visioning end-goal of 2.0. Likewise, Johns case is yet another example of why we need the ability to assign such identifiers rather than have them assigned internally. And because John seeks to supply an updated version of the file with the requirement that he not have to remove all the bitstreams and recreate them in order reconstruct all the local references to that specific bitstream within his item, its a reasonable use case. I encountered this when creating the DDI metadata (relative URI) describing the data files I ported from the Virtual Data Center to DSpace. http://dspace.mit.edu/handle/1721.1/39118 Where I might have: http://dspace.mit.edu/bitstream/handle/1721.1/39126/1/study.xml How would I define my DDI's relative references to the other bitstreams prior to having ingested the entire package representing the Item into DSpace, when my external application doesn't have access to this internally generated sequence id until after the fact? (thats
Re: [Dspace-tech] Reusing bitstream sequence number
Richard, I respectfully disagree with you. On Aug 16, 2008, at 6:54 AM, Richard Rodgers wrote: Hi Mark: Let me explain the problem more fully, which is a very simple 'inconvenient truth' about assets: some complex digital objects we we want to submit as one Item have filename duplications. E.g. in directory 'q4' we have 'report.doc', but the same filename in directory 'fy08' with different content. In the face of this, we can: (1) reject the content (duplicate filenames detected! - please correct or resubmit as multiple items), which is unacceptable. Is it really that unacceptable?! I disagree, what use are two files with the same identical name in a DSpace Item? IMHO, it creates ambiguity in an area file name where users expect conformity with conventions. Really, which file would I choose to download if they had the same identical name? On top of this, what would I do with the second file when the OS/Browser asked me if I wanted to replace the first one I just downloaded, I suppose I'd have to rename it to arrive back at a state of being able to tell the two apart? No, instead we should be adopting RESTfull practices here, allowing DSpace to adhere to more conventional expectations. http://en.wikipedia.org/wiki/ Representational_State_Transfer#RESTful_example:_the_World_Wide_Web Here, if DSpace were to take on REST'full practices in its URI conventions, we would be able to do things like versioning and predictable resource naming. For instance, in your example. PUT /bitstream/handle/1234.5/67890/q4/report.doc HTTP/1.1 PUT /bitstream/handle/1234.5/67890/fy0/report.doc HTTP/1.1 Would clearly result in two different bitstreams, whereas if I did do PUT /bitstream/handle/1234.5/67890/report.doc HTTP/1.1 PUT /bitstream/handle/1234.5/67890/report.doc HTTP/1.1 The second would be overwriting the first. Also a legitimate behavior allowing me to replace/version the resource (for which if I chose to expose access to might look like the following)... GET /bitstream/handle/1234.5/67890/report.doc?revision=1 HTTP/1.1 and GET /bitstream/handle/1234.5/67890/report.doc?revision=0 HTTP/1.1 Likewise, we find this relative directory structure convention maintained in many other Internet resource related areas... in fact this is how the SIP METS and OCW IMSCP packaging works based on basic zip files and manifests. But, yet again the DSpace solution breaks the convention in this case. Take a METS/SIP package representing the following... package.zip$mets.xml package.zip$q4/report.doc package.zip$fy08/report.doc In current dspace parlance... might in turn result in... http://host/bitstream/handle/1234.5/67890/1/mets.xml http://host/bitstream/handle/1234.5/67890/2/q4/report.doc http://host/bitstream/handle/1234.5/67890/3/fy08/report.doc And now where the original relative references in the mets.xml were proper in relation to the files in the zip, they are now NOT when looking that the resultant URL's in DSpace. Now, thats what I call an inconvenient PITA. And it comes up here with Johns issue, it came up in my DDI/VDC work, it came up again in Carl Jones work with the RVC/Stellar support and it was happening again with our attempting to predict the location of GIS files in a DSpace Items for the Dome GIS Lab interoperability work. Not good. Finally, on the Dissemination naming side, this breaks yet again. If I were instead to have the following item in DSpace: http://host/bitstream/handle/1234.5/67890/1/mets.xml http://host/bitstream/handle/1234.5/67890/2/report.doc http://host/bitstream/handle/1234.5/67890/3/report.doc I can't now use the file names to represent the files in the METS DIP. How can I have two different Zip Entries with the same file name? package.zip$mets.xml package.zip$report.doc package.zip$report.doc Just doesn't expand without one of the files getting overwritten. No, this is a serious problem in the original design that is causing users/developers who expect conventional behavior and can't get it out of DSpace. (2) accept the content, but transform or rewrite into unique filenames (q4-report.doc? report[2].doc?, etc?), which is almost as bad, since we now have both obscured the original name, and altered what we are supposed to be preserving. Wow, something we do agree on, that would be a truly awful solution. But yet, thats just what OS's and Browsers do, isn't it. or (3) [what DSpace currently does] store the filename as *metadata*, which, like file size, can be valuable, but which may not be unique, and use a different identification system that *guarantees* uniqueness within the item (sequence id). Which unfortunately, (yet again) immediately diverges from the common expectations on files in a filesystem. The allowance of duplicate file names actually introduces the entire problem we are talking about into DSpace because of a deviation from convention. Because the
