Re: [Dspace-tech] Meatadata dates stored as UTC

2010-06-30 Thread TAYLOR Robin
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

2010-06-30 Thread mikan.d.dspace listmail
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

2010-06-30 Thread LeVan,Ralph
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

2010-06-30 Thread Mark H. Wood
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

2010-06-30 Thread Kim Shepherd
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)

2010-06-30 Thread Gagan

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