Re: [Dspace-tech] Meatadata dates stored as UTC
Hi Kim, Thanks for the feedback, I'm pointlessly tying myself in knots about this. I think storing in Zulu time makes sense, personally -- if somebody in the USA takes a photograph, and records that date in item metadata, I'd want it converted to Zulu so it could be displayed to me in my local time zone (regardless of who was/wasn't in daylight savings time at the time of recording, time of display, etc..). I was looking at a series of photos of Mt St Helens prior to its eruption. It struck me that the date and time recorded were part of a context. It was crucial to know that it was 2.00pm on 29th June 1999 at Mt St Helens in the US. If the date and time are converted to another local time they lose their meaning, unless you are bright enough and have enough information to convert the time back to what it would have been. I think you can make an argument that any dates and times entered as metadata relating to the object, as opposed to administrative metadata eg date accessioned, should be stored as entered by the user. Its not the place of the software to guess what the context is and mess around with it. To be honest I'm not even sure that administrative metadata dates need to be UTC but I'll worry about that later. Cheers, Robin. However, as Robin says, without any proper way to determine what a date field is (besides assuming that people use the usual DC suspects like dc.date.*), converting back to local time on display isn't always going to work. In January, the idea of adding an encoding field to the metadatavalue table was floated by Graham Triggs, as he wanted to find a tidy way to store OpenURL Context objects (specifically, machine-readable bibliographic citations in kev:ctx). I'm pretty sure it's still on the agenda for the next major release..? (correct me if I'm wrong?) Would allowing users to specify W3CDTF as an encoding scheme for a metadata field help get around the we don't know what a date is problem? I realise it's a slight tangent from the discussion around bibliographicCitation, because the recommendation there was to store two values for that one DC term (in our case, element) and just encode one value as kev:ctx. I'm just thinking aloud too.. I know we shouldn't treat database schema changes lightly, but if this is a way of ensuring that DSpace can expose encoding scheme along with metadata values in embedded page metadata, and/or a way of ensuring that DSpace knows how to treat a value by checking the encoding scheme for the metadata field itself, it might be worth considering.. Finally, to get back to the point, if a date cannot be converted to my local time zone from its stored value in DSpace, I'd prefer to see UTC/Zulu than somebody else's (eg. the depositor/creator) local time. Just my personal preference ;-) Cheers! Kim On 28 June 2010 20:49, TAYLOR Robin robin.tay...@ed.ac.uk wrote: Hi Tom, They're stored in Zulu time, which has the advantage of not being dependent on time zones or daylight savings. But I guess my question is, why is that an advantage ? I can see some advantages eg searching and sorting, but I can also see cases where it would not be the right thing to do eg recording when a photograph was taken. In fact I can see advantages and disadvantages in every possible scenario. The best thing to do is to store them in this timezone, but to convert them on display to the local time. I suppose so, but that means recording somewhere which metadata terms are dates, bearing in mind that there is no obligation to use Dublin Core. Currently this is done in input-forms.xml but that only applies to the metadata collected in the 'describe' step, not automatically generated metadata. Apologies for thinking this through 'out loud', it just helps. Cheers, Robin. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] DSPace 1.6.2 with SRU/W
I've been running SRW application (OCLC Research SRW Server 2.0) with DSpace 1.5.x for quite some time now. After I upgraded to DSpace 1.6.2 I cannot seem to make it work. When I compile the code i get 7 errors with deprecated classes (below). Any ideas whats wrong and how can I fix it? thanks, Mika --- compileSRW: jarSRW: compileSRWDSpaceLucene: [javac] Compiling 3 source files to /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/build [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:31: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] import org.dspace.content.DCValue; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:70: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] private String makeDCRecord(DCValue[] values) { [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:50: cannot find symbol [javac] symbol : class Browse [javac] location: package org.dspace.browse [javac] import org.dspace.browse.Browse; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:52: cannot find symbol [javac] symbol : class BrowseScope [javac] location: package org.dspace.browse [javac] import org.dspace.browse.BrowseScope; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:71: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] DCValue value; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:96: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] DCValue[] values=lqr.resultItems[(int)whichRecord].getDC(Item.ANY, Item.ANY, Item.ANY); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:96: warning: [deprecation] getDC(java.lang.String,java.lang.String,java.lang.String) in org.dspace.content.Item has been deprecated [javac] DCValue[] values=lqr.resultItems[(int)whichRecord].getDC(Item.ANY, Item.ANY, Item.ANY); [javac]^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:242: cannot find symbol [javac] symbol : class BrowseScope [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] BrowseScope scope = new BrowseScope(dspaceContext); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:242: cannot find symbol [javac] symbol : class BrowseScope [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] BrowseScope scope = new BrowseScope(dspaceContext); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:275: cannot find symbol [javac] symbol : variable Browse [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] bi=Browse.getAuthors(scope); [javac]^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:276: incompatible types [javac] found : java.lang.String[][] [javac] required: java.lang.String[] [javac] result=bi.getStringResults(); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:279: cannot find symbol [javac] symbol : variable Browse [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] bi=Browse.getItemsByTitle(scope); [javac]^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:281: warning: [deprecation] getItemResults() in org.dspace.browse.BrowseInfo has been deprecated [javac] Item[] item=bi.getItemResults(); [javac]
Re: [Dspace-tech] DSPace 1.6.2 with SRU/W
Where are you getting your code from? I've not tried to build with 1.6.2 yet, but it was working for 1.6.1, so I wouldn't expect any surprises. Ralph -Original Message- From: mikan.d.dspace listmail [mailto:mikan.dsp...@gmail.com] Sent: Wednesday, June 30, 2010 7:44 AM To: Dspace Tech Subject: [Dspace-tech] DSPace 1.6.2 with SRU/W I've been running SRW application (OCLC Research SRW Server 2.0) with DSpace 1.5.x for quite some time now. After I upgraded to DSpace 1.6.2 I cannot seem to make it work. When I compile the code i get 7 errors with deprecated classes (below). Any ideas whats wrong and how can I fix it? thanks, Mika --- compileSRW: jarSRW: compileSRWDSpaceLucene: [javac] Compiling 3 source files to /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW-2.0/build [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:31: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] import org.dspace.content.DCValue; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:70: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] private String makeDCRecord(DCValue[] values) { [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:50: cannot find symbol [javac] symbol : class Browse [javac] location: package org.dspace.browse [javac] import org.dspace.browse.Browse; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:52: cannot find symbol [javac] symbol : class BrowseScope [javac] location: package org.dspace.browse [javac] import org.dspace.browse.BrowseScope; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:71: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] DCValue value; [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:96: warning: [deprecation] org.dspace.content.DCValue in org.dspace.content has been deprecated [javac] DCValue[] values=lqr.resultItems[(int)whichRecord].getDC(Item.ANY, Item.ANY, Item.ANY); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/LuceneRecordIterator.java:96: warning: [deprecation] getDC(java.lang.String,java.lang.String,java.lang.String) in org.dspace.content.Item has been deprecated [javac] DCValue[] values=lqr.resultItems[(int)whichRecord].getDC(Item.ANY, Item.ANY, Item.ANY); [javac]^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:242: cannot find symbol [javac] symbol : class BrowseScope [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] BrowseScope scope = new BrowseScope(dspaceContext); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:242: cannot find symbol [javac] symbol : class BrowseScope [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] BrowseScope scope = new BrowseScope(dspaceContext); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:275: cannot find symbol [javac] symbol : variable Browse [javac] location: class ORG.oclc.os.SRW.DSpaceLucene.SRWLuceneDatabase [javac] bi=Browse.getAuthors(scope); [javac]^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:276: incompatible types [javac] found : java.lang.String[][] [javac] required: java.lang.String[] [javac] result=bi.getStringResults(); [javac] ^ [javac] /home/neuroportti/dikk/SRU_DSpace asennuspaketti/SRW/SRW- 2.0/src/ORG/oclc/os/SRW/DSpaceLucene/SRWLuceneDatabase.java:279: cannot find symbol [javac] symbol : variable Browse [javac]
Re: [Dspace-tech] Meatadata dates stored as UTC
The problem is that sometimes the most useful time zone is that of the context of the object, and sometimes it is that of the user. The software *cannot* know which is correct; only the user knows. Thus, no matter what zone we use, sometimes conversion will be wanted. So, either we always assume a common zone, or (for metadata provided by the user rather than the software) we ask the depositor to specify, with what we may hope is an appropriate default, or we ask the end user to specify (again with a default). If the depositor specifies, then date fields will need to be augmented with the display timezone. Actually, I would argue that both the depositor and the end user be given the ability to specify which timezone is most relevant. Any way we do it, however, the stored values should all be in the same zone, and for simplicity of conversion I'd recommend Z. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgpLU081Jj5zo.pgp Description: PGP signature -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Meatadata dates stored as UTC
Robin wrote: I was looking at a series of photos of Mt St Helens prior to its eruption. It struck me that the date and time recorded were part of a context. It was crucial to know that it was 2.00pm on 29th June 1999 at Mt St Helens in the US. If the date and time are converted to another local time they lose their meaning, unless you are bright enough and have enough information to convert the time back to what it would have been. Oh... good point. In this particular case, it would have been better to store the time with a proper timezone designator so that there was enough information to restore the date to the creator's local time, but we're still lacking the information that says this date ought to be viewed in the creator's local time, or the local time of the region in which the event occurred. (also, in the case of photos, I know that JPEG exif metadata doesn't store timezone designators without some extra work, so often you'll get dates that are still in original local time, but have no timezone offsets) I see Mark put it better than me anyway: On 1 July 2010 02:34, Mark H. Wood mw...@iupui.edu wrote: The problem is that sometimes the most useful time zone is that of the context of the object, and sometimes it is that of the user. The software *cannot* know which is correct; only the user knows. Thus, no matter what zone we use, sometimes conversion will be wanted. Depending on how rich/accurate the metadata you get from depositors is, and how fancy you want to make the interface, there may still be ways to allow this user-level context selection. Any View this date in X timezone features in UIs would still require something like an encoding scheme for metadata values so that dates could be properly detected. -k. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] statistics not working (ver 1.4.2)
Hi, We are successfully running DSpace 1.4.2 for our Library. But the 'statistics' link does not work. (when clicked, shows empty page). The \reports folder is empty; Can _someone pls guide us the exact steps for ver 1.4.2. only_. we manually ran each of the 6 perl scripts [ of stats] ; still no luck; thanks-gagan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech