Re: [Dspace-tech] Sitemaps

[Sean Carte]

On 31 October 2013 04:29, Andrea Schweer  wrote:

> On 30/10/13 21:20, Sean Carte wrote:
> > It would be great if I could find a way to speed up the resolution of
> > handle links. Any ideas?
>
> When I had this issue in one of "my" repositories, it came down to
> firewall settings. This is what the CNRI people told us back then:
>
> > It doesn't look like udp on port 2641 is opened.  By default clients
> > try udp first and when it times out move onto tcp(2641) then
> > http(8000). I can disable it in the prefix record if you can't get
> > your sys admin folks to open it. Resolution will be much faster.
>
> So you might want to make sure that you allow incoming UDP traffic to
> port 2641 or else contact the CNRI people so they disable the UDP lookup
> for your prefix.


Thanks, Andrea and Hilton. I added the necessary to rules to my IR's
firewall and hdl links now resolve in a few seconds! This is a huge
improvement! Thank you!

Sean
--
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Sitemaps

[Hilton Gibson]

I remember. See:
http://wiki.lib.sun.ac.za/index.php/SUNScholar/Handle_Server#Step_8_-_Firewall_Ports



On 31 October 2013 04:29, Andrea Schweer  wrote:

> Hi,
>
> On 30/10/13 21:20, Sean Carte wrote:
> > It would be great if I could find a way to speed up the resolution of
> > handle links. Any ideas?
>
> When I had this issue in one of "my" repositories, it came down to
> firewall settings. This is what the CNRI people told us back then:
>
> > It doesn't look like udp on port 2641 is opened.  By default clients
> > try udp first and when it times out move onto tcp(2641) then
> > http(8000). I can disable it in the prefix record if you can't get
> > your sys admin folks to open it. Resolution will be much faster.
>
> So you might want to make sure that you allow incoming UDP traffic to
> port 2641 or else contact the CNRI people so they disable the UDP lookup
> for your prefix.
>
> cheers,
> Andrea
>
> --
> Dr Andrea Schweer
> IRR Technical Specialist, ITS Information Systems
> The University of Waikato, Hamilton, New Zealand
>
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>



-- 
*Hilton Gibson*
Ubuntu Linux Systems Administrator
JS Gericke Library
Room 1025D
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758
http://library.sun.ac.za
http://za.linkedin.com/in/hiltongibson
http://staff.lib.sun.ac.za/~hgibson/docs/cv/cv.html
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Sitemaps

[Andrea Schweer]

Hi,

On 30/10/13 21:20, Sean Carte wrote:
> It would be great if I could find a way to speed up the resolution of
> handle links. Any ideas?

When I had this issue in one of "my" repositories, it came down to
firewall settings. This is what the CNRI people told us back then:

> It doesn't look like udp on port 2641 is opened.  By default clients
> try udp first and when it times out move onto tcp(2641) then
> http(8000). I can disable it in the prefix record if you can't get
> your sys admin folks to open it. Resolution will be much faster.

So you might want to make sure that you allow incoming UDP traffic to
port 2641 or else contact the CNRI people so they disable the UDP lookup
for your prefix.

cheers,
Andrea

-- 
Dr Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

[Dspace-tech] How to install dpsace-CRIS in existing DSpace 3.x

[LifeH2O]

DSPace 3.2 (JSPUI)

How to install dpsace-CRIS module in the existing DSpace 3.x (DSpace 3.2)
installation? 

https://github.com/CILEA/DSpace/tree/dspace-cris-3.2.0-beta is complete
DSpace with CRIS.
https://github.com/CILEA/dspace-cris/tree/dspace-cris-3.2.0-beta is only
module I think but I have no idea how to put it in existing system. 

I have download both of them as .zip files. git commands are difficult



--
View this message in context: 
http://dspace.2283337.n4.nabble.com/How-to-install-dpsace-CRIS-in-existing-DSpace-3-x-tp4668527.html
Sent from the DSpace - Tech mailing list archive at Nabble.com.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Solr config parameter interpolation

[Andrea Bollini]

  
  
Hi all,
  I have merged "the safer approach" to restore our previous
  configuration for autocommit as in PR#368 provided by Andrea
  Pascarelli.
  https://github.com/DSpace/DSpace/pull/368
  As we can do better, see links send before by AndreaP or this most
  concise but well done blog article
http://www.opensourceconnections.com/2013/04/25/understanding-solr-soft-commits-and-data-durability/
  
  I highly suggest that others will take a look to the PR#370. I
  will prefer to have this change widely tested so I suggest to get
  it in before RC1 (so to use it during testhaton) or postpone it to
  a 4.1
  https://github.com/DSpace/DSpace/pull/370
  
  Andrea
  
  
  
  Il 29/10/2013 10.58, Pascarelli Luigi Andrea ha scritto:


  
  To be thorough, autoCommit works doing commit every 15sec but do
  that not cause a new searcher to be opened to make changes visible
  (because openSearcher is set to false). The parameter
  autoSoftCommit is setted by default to -1 meaning that no action
  to do. So having openSearcher=false is not the best choice, maybe
  try to change that setting could be not need to do a soft commit
  either the change proposed by me in the previous email. Surely
  have sense to change the configuration to obtain an autoCommit
  every 10sec or maxDocs reach the 1 documents (like the old
  DSpace solrconfig.xml says). Note that this changes would to apply
  to all Solr core used by DSpace (search/statistics/oai).
  For more informations see:
  https://cwiki.apache.org/confluence/display/solr/UpdateHandlers+in+SolrConfig
  https://cwiki.apache.org/confluence/display/solr/Near+Real+Time+Searching
  
  Regards,
  
  Luigi Andrea
  
  Il 29/10/2013 01:37, Pascarelli Luigi
Andrea ha scritto:
  
  

Hi all,
solr supports system property substitution as you can see at http://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
So the two mentioned parameters can be tuned as you like using
autoCommit and autoSoftCommit features.
The strange behaviour noticed by Robin is because the discovery
consumer call an index method that do not call the
programmatically solr commit, which the update-discovery do well
(as noticed by helix).
Imho the https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/discovery/IndexEventConsumer.java#L170
could be modified with calling the "void indexContent(Context
context, DSpaceObject dso, boolean force, boolean commit)"
method and force commit to true (or get this information from
configuration to left the user to use autoSoftCommit in case the
commit property is false)
Hope this helps.

Regards,

Luigi Andrea

Il 18/10/2013 15:57, TAYLOR Robin
  ha scritto:


  Hi,

I suspect, but I am definitely not sure, that no automatic commits will be
done with the config as it is. If I run an 'optimize' using the Solr Admin
client, or restart Tomcat, then the indices get updated. Not a big issue,
I think we maybe just need to set some default values. I'll do a wee bit
more investigation.

Cheers.

 

On 18/10/2013 14:43, "helix84"  wrote:


  
I can confirm I'm seeing the same thing in DSpace 4 and that DSpace 3
had actual numbers there. I join you in your confusion.

Can you observe any ill effects? I didn't notice anything wrong and I
ran "update-discovery-index -f" on ~20k items yesterday.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

  


-- 
  
  
  
  
  

  

 

Luigi Andrea Pascarelli
   Dipartimento Servizi e Soluzioni per
  l'Amministrazione Universitaria
  Divisione Ricerca
  Via dei Tizii, 6 
00185 Roma, Italy 
  ph. +39 06 59292895
http://www.cineca.it
  
  

  
  




--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk



___
DSpac

Re: [Dspace-tech] submissions awaiting approval

[Bram Luyten]

This is possible in JSPUI, but remains to be added to XMLUI.

In JSP this feature is called "Current Active Workflows" and is accessible
from the link "Workflows" in the Administer menu. Stepping in and approving
"on behalf of" can be done using the login-as feature once you know who the
person is where the item is stuck.

[image: Inline image 1]

The TODO for XMLUI has been logged in JIRA:
https://jira.duraspace.org/browse/DS-521


-- 
[image: logo]
*Bram Luyten* *@mire*
*2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
www.atmire.com


On Wed, Oct 30, 2013 at 5:41 PM, Ingram, William A wrote:

>  Is there a way for admins to view the list of submissions awaiting
> approval? 
>
> ** **
>
> As I understand it, if you are the collection administrator or reviewer,
> you see a list of submissions that need your approval under My DSpace. But
> we have a situation that requires the repository admin to step in and
> approve a submission—I’m not sure what the details are, specifically. 
>
> ** **
>
> How can she approve the submission if she is not the designated
> approver/reviewer? 
>
> ** **
>
> Sorry if I’m getting the terminology wrong. 
>
> ** **
>
> Thanks!
>
> Bill
>
> -- 
>
> Bill Ingram
>
> Scholarly Communication and
>
> Repository Services
>
> University of Illinois at Urbana-Champaign
>
> 135 GELIC, MC274
>
> 1301 W. Springfield Ave.
>
> Urbana, IL 61801
>
> 217-333-4648
>
> wingr...@illinois.edu
>
> ** **
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
<>--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

[Dspace-tech] submissions awaiting approval

[Ingram, William A]

Is there a way for admins to view the list of submissions awaiting approval?

As I understand it, if you are the collection administrator or reviewer, you 
see a list of submissions that need your approval under My DSpace. But we have 
a situation that requires the repository admin to step in and approve a 
submission-I'm not sure what the details are, specifically.

How can she approve the submission if she is not the designated 
approver/reviewer?

Sorry if I'm getting the terminology wrong.

Thanks!
Bill
--
Bill Ingram
Scholarly Communication and
Repository Services
University of Illinois at Urbana-Champaign
135 GELIC, MC274
1301 W. Springfield Ave.
Urbana, IL 61801
217-333-4648
wingr...@illinois.edu

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

> The next problem is dis-aggregating the dc.type.* attributes - I'm about to 
> start
> investigating this, but if anyone has any pointers as to where to look (is 
> this
> code or configuration?) that would be very helpful.

D'oh! OK, I now officially feel stupid :-)

It turns out that in "ye olden days" before our EThOS integration, we used to 
keep the Publication Type, Qualification Type, and Qualification Level in 
dc.type as a single, concatenated string, but, for thesis records added after 
the integration, these were separated out into the appropriate dc.type, 
dc.type.qualificationname, and dc.type.qualificationlevel attributes.

So, I was expecting to see these three separate attributes in the OAI-PMH 
metadata, but, of course, the first records returned are our oldest, where all 
this data is in the single field - if I page through a few records, I come to 
those where this info is held in separate attributes in DSpace, and these 3 
attributes do, correctly, appear in the OAI-PMH mapped to their corresponding 
uketd_dc terms :-)

So, this is not an issue that needs to be looked into and was merely me being 
stupid (or, perhaps being slightly kinder, a little forgetful) :-)

Apologies for the noise and any confusion or concern!

Cheers,

Mike

Michael White 
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling 
Stirling SCOTLAND 
FK9 4LA 
Email: michael.wh...@stir.ac.uk 
Tel: +44 (0) 1786 466877 
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld


> -Original Message-
> From: Michael White
> Sent: 30 October 2013 14:37
> To: 'Needham, Paul'; João Melo
> Cc: dspace-tech@lists.sourceforge.net
> Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> 
> Hi Paul,
> 
> > * EThOS does expect *only* theses to be exposed using uketd_dc via
> > OAI-PMH
> > * '1. Filtering and Metadata Format tied' is the preferred solution in
> > this instance
> 
> Many thanks for the confirmation/clarification - and, thanks to the fully
> formed example provided by João Melo (cheers!), I now have this working in
> my v3 DEV repository - i.e. I'm now providing (pretty good, although not yet
> perfect) uketd_dc for the theses only  via
> http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uke
> td_dc :-)
> 
> The next problem is dis-aggregating the dc.type.* attributes - I'm about to 
> start
> investigating this, but if anyone has any pointers as to where to look (is 
> this
> code or configuration?) that would be very helpful.
> 
> Cheers,
> 
> Mike
> 
> Michael White
> eLearning Liaison and Development (eLD)
> Information Services
> S8, Library
> University of Stirling
> Stirling SCOTLAND
> FK9 4LA
> Email: michael.wh...@stir.ac.uk
> Tel: +44 (0) 1786 466877
> Fax: +44 (0) 1786 466880
> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
> 
> 
> > -Original Message-
> > From: Needham, Paul [mailto:p.a.need...@cranfield.ac.uk]
> > Sent: 30 October 2013 14:10
> > To: Michael White; João Melo
> > Cc: dspace-tech@lists.sourceforge.net
> > Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> >
> > Hi Mike
> >
> > Just to confirm:
> >
> > * EThOS does expect *only* theses to be exposed using uketd_dc via
> > OAI- PMH
> > * '1. Filtering and Metadata Format tied' is the preferred solution in
> > this instance
> >
> > Cheers
> > Paul
> >


-- 
The University of Stirling has been ranked in the top 12 of UK universities for 
graduate employment*.
94% of our 2012 graduates were in work and/or further study within six months 
of graduation.
*The Telegraph
The University of Stirling is a charity registered in Scotland, number SC 
011159.


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

> I was checking, looks like this functionality (multiple fields) ins't 
> implemented in DSpace v3, it will be available for v4 - currently under 
> development.

Ah, OK, that's a shame because I was just getting excited about this as one of 
the institutions that provide uketd_dc are using a different field to hold the 
type value they want to filter on - oh well, never mind, one for the future :)

Thanks for the info though - I'm learning a lot about XOAI in a very short time!

Cheers,

Mike
Michael White
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: michael.wh...@stir.ac.uk
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld

From: João Melo [mailto:jm...@lyncode.com]
Sent: 30 October 2013 15:47
To: Michael White
Cc: Needham, Paul; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

Sorry Micheal,

I was checking, looks like this functionality (multiple fields) ins't 
implemented in DSpace v3, it will be available for v4 - currently under 
development.

On 30 October 2013 15:42, João Melo 
mailto:jm...@lyncode.com>> wrote:









 
org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter



 



  dc.type





  dc.type.other





 

 





  contains

 



 



  thesis

 





On 30 October 2013 15:42, João Melo 
mailto:jm...@lyncode.com>> wrote:
Hi Micheal,

you could provide multiple fields do be checked, let's say (for example):










 
org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter



 



  dc.type

 



 



  contains

 



 



  thesis

 







On 30 October 2013 14:37, Michael White 
mailto:michael.wh...@stir.ac.uk>> wrote:
Hi Paul,

> * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-PMH
> * '1. Filtering and Metadata Format tied' is the preferred solution in this 
> instance
Many thanks for the confirmation/clarification - and, thanks to the fully 
formed example provided by João Melo (cheers!), I now have this working in my 
v3 DEV repository - i.e. I'm now providing (pretty good, although not yet 
perfect) uketd_dc for the theses only  via 
http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uketd_dc 
:-)

The next problem is dis-aggregating the dc.type.* attributes - I'm about to 
start investigating this, but if anyone has any pointers as to where to look 
(is this code or configuration?) that would be very helpful.

Cheers,

Mike

Michael White
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: michael.wh...@stir.ac.uk
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld

> -Original Message-
> From: Needham, Paul 
> [mailto:p.a.need...@cranfield.ac.uk]
> Sent: 30 October 2013 14:10
> To: Michael White; João Melo
> Cc: 
> dspace-tech@lists.sourceforge.net
> Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>
> Hi Mike
>
> Just to confirm:
>
> * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-
> PMH
> * '1. Filtering and Metadata Format tied' is the preferred solution in this
> instance
>
> Cheers
> Paul
>
> -Original Message-
> From: Michael White 
> [mailto:michael.wh...@stir.ac.uk]
> Sent: 30 October 2013 13:50
> To: João Melo
> Cc: 
> dspace-tech@lists.sourceforge.net
> Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>
> > Because, there are 2 possible solutions, and the solution depends on
> > what makes sense :)
>
> Many thanks for these pointers, that's really helpful, and all makes sense (on
> first reading anyway) ;-)
>
> My first though is that the first approach is probably what we want in this
> instance, so I take a look at the example and see how far I get!
>
> Thanks again, much appreciated.
>
> Mike
>
> Michael White
> eLearning Liaison and Development (eLD)
> Information Services
> S8, Library
> University of Stirling
> Stirling SCOTLAND
> FK9 4LA
> Email: michael.wh...@stir.ac.uk
> Tel: +44 (0) 1786 466877
> Fax: +44 (0) 1786 466880

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[João Melo]

Sorry Micheal,

I was checking, looks like this functionality (multiple fields) ins't
implemented in DSpace v3, it will be available for v4 - currently under
development.


On 30 October 2013 15:42, João Melo  wrote:

>   
>   
> org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter
>
>   
>
>   dc.type
>
>   dc.type.other
>
> 
> 
>  contains
> 
>  
>  thesis
> 
>  
>
>
>
> On 30 October 2013 15:42, João Melo  wrote:
>
>> Hi Micheal,
>>
>> you could provide multiple fields do be checked, let's say (for example):
>>
>> 
>>
>>  
>> org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter
>>
>>  
>>  dc.type
>>  
>>  
>>  contains
>>  
>>  
>>  thesis
>>  
>>  
>>
>>
>>
>>
>>
>> On 30 October 2013 14:37, Michael White  wrote:
>>
>>> Hi Paul,
>>>
>>> > * EThOS does expect *only* theses to be exposed using uketd_dc via
>>> OAI-PMH
>>> > * '1. Filtering and Metadata Format tied' is the preferred solution in
>>> this instance
>>>
>>> Many thanks for the confirmation/clarification - and, thanks to the
>>> fully formed example provided by João Melo (cheers!), I now have this
>>> working in my v3 DEV repository - i.e. I'm now providing (pretty good,
>>> although not yet perfect) uketd_dc for the theses only  via
>>> http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uketd_dc:-)
>>>
>>> The next problem is dis-aggregating the dc.type.* attributes - I'm about
>>> to start investigating this, but if anyone has any pointers as to where to
>>> look (is this code or configuration?) that would be very helpful.
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>> Michael White
>>> eLearning Liaison and Development (eLD)
>>> Information Services
>>> S8, Library
>>> University of Stirling
>>> Stirling SCOTLAND
>>> FK9 4LA
>>> Email: michael.wh...@stir.ac.uk
>>> Tel: +44 (0) 1786 466877
>>> Fax: +44 (0) 1786 466880
>>> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>>>
>>>
>>> > -Original Message-
>>> > From: Needham, Paul [mailto:p.a.need...@cranfield.ac.uk]
>>> > Sent: 30 October 2013 14:10
>>> > To: Michael White; João Melo
>>> > Cc: dspace-tech@lists.sourceforge.net
>>> > Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>>> >
>>> > Hi Mike
>>> >
>>> > Just to confirm:
>>> >
>>> > * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-
>>> > PMH
>>> > * '1. Filtering and Metadata Format tied' is the preferred solution in
>>> this
>>> > instance
>>> >
>>> > Cheers
>>> > Paul
>>> >
>>> > -Original Message-
>>> > From: Michael White [mailto:michael.wh...@stir.ac.uk]
>>> > Sent: 30 October 2013 13:50
>>> > To: João Melo
>>> > Cc: dspace-tech@lists.sourceforge.net
>>> > Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>>> >
>>> > > Because, there are 2 possible solutions, and the solution depends on
>>> > > what makes sense :)
>>> >
>>> > Many thanks for these pointers, that's really helpful, and all makes
>>> sense (on
>>> > first reading anyway) ;-)
>>> >
>>> > My first though is that the first approach is probably what we want in
>>> this
>>> > instance, so I take a look at the example and see how far I get!
>>> >
>>> > Thanks again, much appreciated.
>>> >
>>> > Mike
>>> >
>>> > Michael White
>>> > eLearning Liaison and Development (eLD)
>>> > Information Services
>>> > S8, Library
>>> > University of Stirling
>>> > Stirling SCOTLAND
>>> > FK9 4LA
>>> > Email: michael.wh...@stir.ac.uk
>>> > Tel: +44 (0) 1786 466877
>>> > Fax: +44 (0) 1786 466880
>>> > http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>>> >
>>>
>>> --
>>> The University of Stirling has been ranked in the top 12 of UK
>>> universities for graduate employment*.
>>> 94% of our 2012 graduates were in work and/or further study within six
>>> months of graduation.
>>> *The Telegraph
>>> The University of Stirling is a charity registered in Scotland, number
>>> SC 011159.
>>>
>>>
>>
>>
>> --
>>  Thanks, João Melo (My Portfolio )
>> DSpace Department
>> *Lyncode*: Official 
>> website
>> [image: Follow us on 
>> Facebook]
>> 
>>
>
>
>
> --
> Thanks, João Melo (My Portfolio )
> DSpace Department
> *Lyncode*: Official 
> website
> [image: Follow us on 
> Facebook]<

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[João Melo]

org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter


dc.type

dc.type.other



contains


thesis





On 30 October 2013 15:42, João Melo  wrote:

> Hi Micheal,
>
> you could provide multiple fields do be checked, let's say (for example):
>
> 
>   
> org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter
>
>   
>   dc.type
>   
>   
>   contains
>   
>   
>   thesis
>   
>   
>
>
>
>
>
> On 30 October 2013 14:37, Michael White  wrote:
>
>> Hi Paul,
>>
>> > * EThOS does expect *only* theses to be exposed using uketd_dc via
>> OAI-PMH
>> > * '1. Filtering and Metadata Format tied' is the preferred solution in
>> this instance
>>
>> Many thanks for the confirmation/clarification - and, thanks to the fully
>> formed example provided by João Melo (cheers!), I now have this working in
>> my v3 DEV repository - i.e. I'm now providing (pretty good, although not
>> yet perfect) uketd_dc for the theses only  via
>> http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uketd_dc:-)
>>
>> The next problem is dis-aggregating the dc.type.* attributes - I'm about
>> to start investigating this, but if anyone has any pointers as to where to
>> look (is this code or configuration?) that would be very helpful.
>>
>> Cheers,
>>
>> Mike
>>
>> Michael White
>> eLearning Liaison and Development (eLD)
>> Information Services
>> S8, Library
>> University of Stirling
>> Stirling SCOTLAND
>> FK9 4LA
>> Email: michael.wh...@stir.ac.uk
>> Tel: +44 (0) 1786 466877
>> Fax: +44 (0) 1786 466880
>> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>>
>>
>> > -Original Message-
>> > From: Needham, Paul [mailto:p.a.need...@cranfield.ac.uk]
>> > Sent: 30 October 2013 14:10
>> > To: Michael White; João Melo
>> > Cc: dspace-tech@lists.sourceforge.net
>> > Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>> >
>> > Hi Mike
>> >
>> > Just to confirm:
>> >
>> > * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-
>> > PMH
>> > * '1. Filtering and Metadata Format tied' is the preferred solution in
>> this
>> > instance
>> >
>> > Cheers
>> > Paul
>> >
>> > -Original Message-
>> > From: Michael White [mailto:michael.wh...@stir.ac.uk]
>> > Sent: 30 October 2013 13:50
>> > To: João Melo
>> > Cc: dspace-tech@lists.sourceforge.net
>> > Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
>> >
>> > > Because, there are 2 possible solutions, and the solution depends on
>> > > what makes sense :)
>> >
>> > Many thanks for these pointers, that's really helpful, and all makes
>> sense (on
>> > first reading anyway) ;-)
>> >
>> > My first though is that the first approach is probably what we want in
>> this
>> > instance, so I take a look at the example and see how far I get!
>> >
>> > Thanks again, much appreciated.
>> >
>> > Mike
>> >
>> > Michael White
>> > eLearning Liaison and Development (eLD)
>> > Information Services
>> > S8, Library
>> > University of Stirling
>> > Stirling SCOTLAND
>> > FK9 4LA
>> > Email: michael.wh...@stir.ac.uk
>> > Tel: +44 (0) 1786 466877
>> > Fax: +44 (0) 1786 466880
>> > http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>> >
>>
>> --
>> The University of Stirling has been ranked in the top 12 of UK
>> universities for graduate employment*.
>> 94% of our 2012 graduates were in work and/or further study within six
>> months of graduation.
>> *The Telegraph
>> The University of Stirling is a charity registered in Scotland, number SC
>> 011159.
>>
>>
>
>
> --
> Thanks, João Melo (My Portfolio )
> DSpace Department
> *Lyncode*: Official 
> website
> [image: Follow us on 
> Facebook]
> 
>



-- 
Thanks, João Melo (My Portfolio )
DSpace Department
*Lyncode*: Official
website
[image: Follow us on
Facebook]

--
Android is increasing in popularity, but the open development platform that
develo

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[João Melo]

Hi Micheal,

you could provide multiple fields do be checked, let's say (for example):



org.dspace.xoai.filter.DSpaceAtLeastOneMetadataFilter

dc.type


contains


thesis







On 30 October 2013 14:37, Michael White  wrote:

> Hi Paul,
>
> > * EThOS does expect *only* theses to be exposed using uketd_dc via
> OAI-PMH
> > * '1. Filtering and Metadata Format tied' is the preferred solution in
> this instance
>
> Many thanks for the confirmation/clarification - and, thanks to the fully
> formed example provided by João Melo (cheers!), I now have this working in
> my v3 DEV repository - i.e. I'm now providing (pretty good, although not
> yet perfect) uketd_dc for the theses only  via
> http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uketd_dc:-)
>
> The next problem is dis-aggregating the dc.type.* attributes - I'm about
> to start investigating this, but if anyone has any pointers as to where to
> look (is this code or configuration?) that would be very helpful.
>
> Cheers,
>
> Mike
>
> Michael White
> eLearning Liaison and Development (eLD)
> Information Services
> S8, Library
> University of Stirling
> Stirling SCOTLAND
> FK9 4LA
> Email: michael.wh...@stir.ac.uk
> Tel: +44 (0) 1786 466877
> Fax: +44 (0) 1786 466880
> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>
>
> > -Original Message-
> > From: Needham, Paul [mailto:p.a.need...@cranfield.ac.uk]
> > Sent: 30 October 2013 14:10
> > To: Michael White; João Melo
> > Cc: dspace-tech@lists.sourceforge.net
> > Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> >
> > Hi Mike
> >
> > Just to confirm:
> >
> > * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-
> > PMH
> > * '1. Filtering and Metadata Format tied' is the preferred solution in
> this
> > instance
> >
> > Cheers
> > Paul
> >
> > -Original Message-
> > From: Michael White [mailto:michael.wh...@stir.ac.uk]
> > Sent: 30 October 2013 13:50
> > To: João Melo
> > Cc: dspace-tech@lists.sourceforge.net
> > Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> >
> > > Because, there are 2 possible solutions, and the solution depends on
> > > what makes sense :)
> >
> > Many thanks for these pointers, that's really helpful, and all makes
> sense (on
> > first reading anyway) ;-)
> >
> > My first though is that the first approach is probably what we want in
> this
> > instance, so I take a look at the example and see how far I get!
> >
> > Thanks again, much appreciated.
> >
> > Mike
> >
> > Michael White
> > eLearning Liaison and Development (eLD)
> > Information Services
> > S8, Library
> > University of Stirling
> > Stirling SCOTLAND
> > FK9 4LA
> > Email: michael.wh...@stir.ac.uk
> > Tel: +44 (0) 1786 466877
> > Fax: +44 (0) 1786 466880
> > http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
> >
>
> --
> The University of Stirling has been ranked in the top 12 of UK
> universities for graduate employment*.
> 94% of our 2012 graduates were in work and/or further study within six
> months of graduation.
> *The Telegraph
> The University of Stirling is a charity registered in Scotland, number SC
> 011159.
>
>


-- 
Thanks, João Melo (My Portfolio )
DSpace Department
*Lyncode*: Official
website
[image: Follow us on
Facebook]

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

Hi Paul,

> * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-PMH
> * '1. Filtering and Metadata Format tied' is the preferred solution in this 
> instance

Many thanks for the confirmation/clarification - and, thanks to the fully 
formed example provided by João Melo (cheers!), I now have this working in my 
v3 DEV repository - i.e. I'm now providing (pretty good, although not yet 
perfect) uketd_dc for the theses only  via 
http://dspace3.stir.ac.uk/oai/request?verb=ListRecords&metadataPrefix=uketd_dc 
:-)

The next problem is dis-aggregating the dc.type.* attributes - I'm about to 
start investigating this, but if anyone has any pointers as to where to look 
(is this code or configuration?) that would be very helpful.

Cheers,

Mike

Michael White 
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling 
Stirling SCOTLAND 
FK9 4LA 
Email: michael.wh...@stir.ac.uk 
Tel: +44 (0) 1786 466877 
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld


> -Original Message-
> From: Needham, Paul [mailto:p.a.need...@cranfield.ac.uk]
> Sent: 30 October 2013 14:10
> To: Michael White; João Melo
> Cc: dspace-tech@lists.sourceforge.net
> Subject: RE: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> 
> Hi Mike
> 
> Just to confirm:
> 
> * EThOS does expect *only* theses to be exposed using uketd_dc via OAI-
> PMH
> * '1. Filtering and Metadata Format tied' is the preferred solution in this
> instance
> 
> Cheers
> Paul
> 
> -Original Message-
> From: Michael White [mailto:michael.wh...@stir.ac.uk]
> Sent: 30 October 2013 13:50
> To: João Melo
> Cc: dspace-tech@lists.sourceforge.net
> Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> 
> > Because, there are 2 possible solutions, and the solution depends on
> > what makes sense :)
> 
> Many thanks for these pointers, that's really helpful, and all makes sense (on
> first reading anyway) ;-)
> 
> My first though is that the first approach is probably what we want in this
> instance, so I take a look at the example and see how far I get!
> 
> Thanks again, much appreciated.
> 
> Mike
> 
> Michael White
> eLearning Liaison and Development (eLD)
> Information Services
> S8, Library
> University of Stirling
> Stirling SCOTLAND
> FK9 4LA
> Email: michael.wh...@stir.ac.uk
> Tel: +44 (0) 1786 466877
> Fax: +44 (0) 1786 466880
> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
> 

-- 
The University of Stirling has been ranked in the top 12 of UK universities for 
graduate employment*.
94% of our 2012 graduates were in work and/or further study within six months 
of graduation.
*The Telegraph
The University of Stirling is a charity registered in Scotland, number SC 
011159.


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Needham, Paul]

Hi Mike

Just to confirm: 

* EThOS does expect *only* theses to be exposed using uketd_dc via OAI-PMH
* '1. Filtering and Metadata Format tied' is the preferred solution in this 
instance

Cheers
Paul

-Original Message-
From: Michael White [mailto:michael.wh...@stir.ac.uk] 
Sent: 30 October 2013 13:50
To: João Melo
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

> Because, there are 2 possible solutions, and the solution depends on 
> what makes sense :)

Many thanks for these pointers, that's really helpful, and all makes sense (on 
first reading anyway) ;-) 

My first though is that the first approach is probably what we want in this 
instance, so I take a look at the example and see how far I get!

Thanks again, much appreciated.

Mike

Michael White
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling
Stirling SCOTLAND
FK9 4LA
Email: michael.wh...@stir.ac.uk
Tel: +44 (0) 1786 466877
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld

From: João Melo [mailto:jm...@lyncode.com]
Sent: 30 October 2013 13:44
To: Michael White
Cc: heli...@centrum.sk; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

Because, there are 2 possible solutions, and the solution depends on what makes 
sense :) - yeh! It makes sense to make sense.

1. Filtering and Metadata Format tied

This solution associates to the Format definition a Filter, so then, for this 
specific Schema/Format, only a subset of items would be shown.
You may want to look at the following example.

https://gist.github.com/lyncodev/7232812

Basically, it specifies a Filter within the Format, so then you could query the 
OAI interface with something like:

http://:/oai/request?verb=ListRecords&metadataPrefix=uketd_dc

2. Filtering and Metadata Format decoupled

This solution decouples the Item Selection phase from the Formatting phase.
It requires a 2 steps:

1 - Configure one specific set (or context) to select only Thesis items.
2 - Modify the uketd_dc format accordingly.

So then it would be possible to query the OAI interface for thesis items using 
that format. Something like: 
http://:/oai/request?verb=ListRecords&set=thesis&metadataPrefix=uketd_dc

On 30 October 2013 13:07, João Melo  wrote:
Hi Michael,

My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

Just a simple question. Makes sense to use uketd_dc schema for non-thesis types?


On 30 October 2013 11:51, Michael White  wrote:
Hi,

> Please, file a new Jira issue for this:
With apologies for the delay getting around to it, but I have now done this: 
https://jira.duraspace.org/i#browse/DS-1740 - this is my first time adding a 
JIRA ticket, so I hope everything is OK, but feel free to let me know or change 
anything if not :-)

> > > - the output is not limited to only "Theses"
>
> What metadata field and value(s) in DSpace specifies that the item is a 
> thesis?
My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

In terms of dc.type - I've also noted an issue with this attribute - it looks 
to me like any dc.type or dc.type.* attributes are being concatenated into a 
single dc.type attribute before the data reaches the uketd_dc crosswalk (? 
Please correct me if I'm wrong!)  - I don't think this behaviour is correct in 
uketd_dc as there are a couple of qualified dc.type attributes that are mapped 
to their own uketd_dc elements, so I'm hoping that it will be possible to 
prevent this behaviour when generating uketd_dc OAI metadata (again, not had a 
chance to look myself yet, but will!)?

> Please, provide the mapping of DSpace fields to uketd_dc fields (this 
> will be an update to uketd_dc.xsl).
I am currently working on this specification, which is nearly complete, and 
liaising with other institutions to ensure that the specified 

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

> Because, there are 2 possible solutions, and the solution depends on what 
> makes sense :)

Many thanks for these pointers, that's really helpful, and all makes sense (on 
first reading anyway) ;-) 

My first though is that the first approach is probably what we want in this 
instance, so I take a look at the example and see how far I get!

Thanks again, much appreciated.

Mike

Michael White 
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling 
Stirling SCOTLAND 
FK9 4LA 
Email: michael.wh...@stir.ac.uk 
Tel: +44 (0) 1786 466877 
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld

From: João Melo [mailto:jm...@lyncode.com] 
Sent: 30 October 2013 13:44
To: Michael White
Cc: heli...@centrum.sk; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

Because, there are 2 possible solutions, and the solution depends on what makes 
sense :) - yeh! It makes sense to make sense.

1. Filtering and Metadata Format tied

This solution associates to the Format definition a Filter, so then, for this 
specific Schema/Format, only a subset of items would be shown.
You may want to look at the following example.

https://gist.github.com/lyncodev/7232812

Basically, it specifies a Filter within the Format, so then you could query the 
OAI interface with something like:

http://:/oai/request?verb=ListRecords&metadataPrefix=uketd_dc

2. Filtering and Metadata Format decoupled

This solution decouples the Item Selection phase from the Formatting phase.
It requires a 2 steps:

1 - Configure one specific set (or context) to select only Thesis items.
2 - Modify the uketd_dc format accordingly.

So then it would be possible to query the OAI interface for thesis items using 
that format. Something like: 
http://:/oai/request?verb=ListRecords&set=thesis&metadataPrefix=uketd_dc

On 30 October 2013 13:07, João Melo  wrote:
Hi Michael,

My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

Just a simple question. Makes sense to use uketd_dc schema for non-thesis types?


On 30 October 2013 11:51, Michael White  wrote:
Hi,

> Please, file a new Jira issue for this:
With apologies for the delay getting around to it, but I have now done this: 
https://jira.duraspace.org/i#browse/DS-1740 - this is my first time adding a 
JIRA ticket, so I hope everything is OK, but feel free to let me know or change 
anything if not :-)

> > > - the output is not limited to only "Theses"
>
> What metadata field and value(s) in DSpace specifies that the item is a 
> thesis?
My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

In terms of dc.type - I've also noted an issue with this attribute - it looks 
to me like any dc.type or dc.type.* attributes are being concatenated into a 
single dc.type attribute before the data reaches the uketd_dc crosswalk (? 
Please correct me if I'm wrong!)  - I don't think this behaviour is correct in 
uketd_dc as there are a couple of qualified dc.type attributes that are mapped 
to their own uketd_dc elements, so I'm hoping that it will be possible to 
prevent this behaviour when generating uketd_dc OAI metadata (again, not had a 
chance to look myself yet, but will!)?

> Please, provide the mapping of DSpace fields to uketd_dc fields (this will be
> an update to uketd_dc.xsl).
I am currently working on this specification, which is nearly complete, and 
liaising with other institutions to ensure that the specified mapping is as 
generic as possible and so will work for the majority of institutions "out of 
the box" - alongside this I'm also creating a uketd_dc.xsl crosswalk that 
implements that specification, and, once complete, hopefully the folk from 
EThOS will be able to validate the output for us.

I'm hoping that all this will only take a couple of weeks to sort out (other 
work commitments allowing), but that may,

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[João Melo]

Because, there are 2 possible solutions, and the solution depends on what
makes sense :) - yeh! It makes sense to make sense.

*1. Filtering and Metadata Format tied*

This solution associates to the Format definition a Filter, so then, for
this specific Schema/Format, only a subset of items would be shown.
You may want to look at the following example.

https://gist.github.com/lyncodev/7232812

Basically, it specifies a Filter within the Format, so then you could query
the OAI interface with something like:

http://**:**/oai/request?verb=ListRecords&metadataPrefix=*
uketd_dc*

*2. Filtering and Metadata Format decoupled*

This solution decouples the Item Selection phase from the Formatting phase.
It requires a 2 steps:

1 - Configure one specific set (or context) to select only Thesis items.
2 - Modify the uketd_dc format accordingly.

So then it would be possible to query the OAI interface for thesis items
using that format. Something like: http://**:**
/oai/request?verb=ListRecords&set=*thesis*&metadataPrefix=*uketd_dc*


On 30 October 2013 13:07, João Melo  wrote:

> Hi Michael,
>
> *My understanding is that this is in dc.type - I'm currently liaising
> with a number of other DSpace users that participate in the EThOS service
> (the primary consumers of uketd_dc metadata) as there may well be more than
> one value - I'm hoping though that all the different variations will, at
> the very least, all contain the word "Thesis", so my first question is to
> ask if you know if it is possible to use pattern matching to carry out the
> filtering in xoai.xsl? I am intending to investigate this further, I just
> haven't got to it yet, but if anyone knows the answer it would be helpful
> at this stage!*
>
> Just a simple question. Makes sense to use uketd_dc schema for non-thesis
> types?
>
>
>
> On 30 October 2013 11:51, Michael White  wrote:
>
>> Hi,
>>
>> > Please, file a new Jira issue for this:
>>
>> With apologies for the delay getting around to it, but I have now done
>> this: https://jira.duraspace.org/i#browse/DS-1740 - this is my first
>> time adding a JIRA ticket, so I hope everything is OK, but feel free to let
>> me know or change anything if not :-)
>>
>> > > > - the output is not limited to only "Theses"
>> >
>> > What metadata field and value(s) in DSpace specifies that the item is a
>> thesis?
>>
>> My understanding is that this is in dc.type - I'm currently liaising with
>> a number of other DSpace users that participate in the EThOS service (the
>> primary consumers of uketd_dc metadata) as there may well be more than one
>> value - I'm hoping though that all the different variations will, at the
>> very least, all contain the word "Thesis", so my first question is to ask
>> if you know if it is possible to use pattern matching to carry out the
>> filtering in xoai.xsl? I am intending to investigate this further, I just
>> haven't got to it yet, but if anyone knows the answer it would be helpful
>> at this stage!
>>
>> In terms of dc.type - I've also noted an issue with this attribute - it
>> looks to me like any dc.type or dc.type.* attributes are being concatenated
>> into a single dc.type attribute before the data reaches the uketd_dc
>> crosswalk (? Please correct me if I'm wrong!)  - I don't think this
>> behaviour is correct in uketd_dc as there are a couple of qualified dc.type
>> attributes that are mapped to their own uketd_dc elements, so I'm hoping
>> that it will be possible to prevent this behaviour when generating uketd_dc
>> OAI metadata (again, not had a chance to look myself yet, but will!)?
>>
>> > Please, provide the mapping of DSpace fields to uketd_dc fields (this
>> will be
>> > an update to uketd_dc.xsl).
>>
>> I am currently working on this specification, which is nearly complete,
>> and liaising with other institutions to ensure that the specified mapping
>> is as generic as possible and so will work for the majority of institutions
>> "out of the box" - alongside this I'm also creating a uketd_dc.xsl
>> crosswalk that implements that specification, and, once complete, hopefully
>> the folk from EThOS will be able to validate the output for us.
>>
>> I'm hoping that all this will only take a couple of weeks to sort out
>> (other work commitments allowing), but that may, of course, be a bit
>> optimistic :-)
>>
>> I hope that covers where I'm currently at and what I'm hoping to achieve,
>> but of course, if anyone has any questions, comments, or concerns (or any
>> pointers for any of the issues noted above), or if you are interested in
>> participating in the specification/testing of this crosswalk (and haven't
>> been in touch so far), then please don't hesitate to get back to me.
>>
>> Regards,
>>
>> Mike
>>
>>
>> Michael White
>> eLearning Liaison and Development (eLD)
>> Information Services
>> S8, Library
>> University of Stirling
>> Stirling SCOTLAND
>> FK9 4LA
>> Email: michael.wh...@stir.ac.uk
>> Tel: +44 (0) 1786 466877
>> Fax: +44 (0) 1786 466880
>> http://www

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

Hi,

> Just a simple question. Makes sense to use uketd_dc schema for non-thesis 
> types?

My understanding is that the uketd_dc schema was specifically devised to 
support the exchange of metadata of eTheses only, primarily for use by the 
EThOS service run by the British Library here in the UK, and it includes 
elements to hold thesis specific information (in uketdterms elements) that 
aren't used for most other publication types – so my understanding is that the 
schema doesn’t really make sense for non-thesis types. 

In my email exchanges with the EThOS folk, they also say (when reviewing the 
incorrect uketd_dc currently being served by DSpace v3.n repositories):

> I’m getting the same results as you, i.e. the uketd_dc output is not limited 
> to theses and I’m not getting any uketdterms elements

- so that certainly seems to confirm that the EThOS service expects uketd_dc 
output to be limited to eTheses only.

However, that is only my understanding so I’m happy to be corrected if anyone 
else on the list knows better? ☺

Cheers,

Mike

Michael White 
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling 
Stirling SCOTLAND 
FK9 4LA 
Email: michael.wh...@stir.ac.uk 
Tel: +44 (0) 1786 466877 
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld

From: João Melo [mailto:jm...@lyncode.com] 
Sent: 30 October 2013 13:08
To: Michael White
Cc: heli...@centrum.sk; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

Hi Michael,

My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

Just a simple question. Makes sense to use uketd_dc schema for non-thesis types?


On 30 October 2013 11:51, Michael White  wrote:
Hi,

> Please, file a new Jira issue for this:
With apologies for the delay getting around to it, but I have now done this: 
https://jira.duraspace.org/i#browse/DS-1740 - this is my first time adding a 
JIRA ticket, so I hope everything is OK, but feel free to let me know or change 
anything if not :-)

> > > - the output is not limited to only "Theses"
>
> What metadata field and value(s) in DSpace specifies that the item is a 
> thesis?
My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

In terms of dc.type - I've also noted an issue with this attribute - it looks 
to me like any dc.type or dc.type.* attributes are being concatenated into a 
single dc.type attribute before the data reaches the uketd_dc crosswalk (? 
Please correct me if I'm wrong!)  - I don't think this behaviour is correct in 
uketd_dc as there are a couple of qualified dc.type attributes that are mapped 
to their own uketd_dc elements, so I'm hoping that it will be possible to 
prevent this behaviour when generating uketd_dc OAI metadata (again, not had a 
chance to look myself yet, but will!)?

> Please, provide the mapping of DSpace fields to uketd_dc fields (this will be
> an update to uketd_dc.xsl).
I am currently working on this specification, which is nearly complete, and 
liaising with other institutions to ensure that the specified mapping is as 
generic as possible and so will work for the majority of institutions "out of 
the box" - alongside this I'm also creating a uketd_dc.xsl crosswalk that 
implements that specification, and, once complete, hopefully the folk from 
EThOS will be able to validate the output for us.

I'm hoping that all this will only take a couple of weeks to sort out (other 
work commitments allowing), but that may, of course, be a bit optimistic :-)

I hope that covers where I'm currently at and what I'm hoping to achieve, but 
of course, if anyone has any questions, comments, or concerns (or any pointers 
for any of the issues noted above), or if you are interested in participating 
in the specification/testing of this crosswalk (and haven't been in touch so 
far), then please don't hesitate to get

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[João Melo]

Hi Michael,

*My understanding is that this is in dc.type - I'm currently liaising with
a number of other DSpace users that participate in the EThOS service (the
primary consumers of uketd_dc metadata) as there may well be more than one
value - I'm hoping though that all the different variations will, at the
very least, all contain the word "Thesis", so my first question is to ask
if you know if it is possible to use pattern matching to carry out the
filtering in xoai.xsl? I am intending to investigate this further, I just
haven't got to it yet, but if anyone knows the answer it would be helpful
at this stage!*

Just a simple question. Makes sense to use uketd_dc schema for non-thesis
types?



On 30 October 2013 11:51, Michael White  wrote:

> Hi,
>
> > Please, file a new Jira issue for this:
>
> With apologies for the delay getting around to it, but I have now done
> this: https://jira.duraspace.org/i#browse/DS-1740 - this is my first time
> adding a JIRA ticket, so I hope everything is OK, but feel free to let me
> know or change anything if not :-)
>
> > > > - the output is not limited to only "Theses"
> >
> > What metadata field and value(s) in DSpace specifies that the item is a
> thesis?
>
> My understanding is that this is in dc.type - I'm currently liaising with
> a number of other DSpace users that participate in the EThOS service (the
> primary consumers of uketd_dc metadata) as there may well be more than one
> value - I'm hoping though that all the different variations will, at the
> very least, all contain the word "Thesis", so my first question is to ask
> if you know if it is possible to use pattern matching to carry out the
> filtering in xoai.xsl? I am intending to investigate this further, I just
> haven't got to it yet, but if anyone knows the answer it would be helpful
> at this stage!
>
> In terms of dc.type - I've also noted an issue with this attribute - it
> looks to me like any dc.type or dc.type.* attributes are being concatenated
> into a single dc.type attribute before the data reaches the uketd_dc
> crosswalk (? Please correct me if I'm wrong!)  - I don't think this
> behaviour is correct in uketd_dc as there are a couple of qualified dc.type
> attributes that are mapped to their own uketd_dc elements, so I'm hoping
> that it will be possible to prevent this behaviour when generating uketd_dc
> OAI metadata (again, not had a chance to look myself yet, but will!)?
>
> > Please, provide the mapping of DSpace fields to uketd_dc fields (this
> will be
> > an update to uketd_dc.xsl).
>
> I am currently working on this specification, which is nearly complete,
> and liaising with other institutions to ensure that the specified mapping
> is as generic as possible and so will work for the majority of institutions
> "out of the box" - alongside this I'm also creating a uketd_dc.xsl
> crosswalk that implements that specification, and, once complete, hopefully
> the folk from EThOS will be able to validate the output for us.
>
> I'm hoping that all this will only take a couple of weeks to sort out
> (other work commitments allowing), but that may, of course, be a bit
> optimistic :-)
>
> I hope that covers where I'm currently at and what I'm hoping to achieve,
> but of course, if anyone has any questions, comments, or concerns (or any
> pointers for any of the issues noted above), or if you are interested in
> participating in the specification/testing of this crosswalk (and haven't
> been in touch so far), then please don't hesitate to get back to me.
>
> Regards,
>
> Mike
>
>
> Michael White
> eLearning Liaison and Development (eLD)
> Information Services
> S8, Library
> University of Stirling
> Stirling SCOTLAND
> FK9 4LA
> Email: michael.wh...@stir.ac.uk
> Tel: +44 (0) 1786 466877
> Fax: +44 (0) 1786 466880
> http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld
>
>
> > -Original Message-
> > From: ivan.ma...@gmail.com [mailto:ivan.ma...@gmail.com] On Behalf Of
> > helix84
> > Sent: 22 October 2013 14:59
> > To: Michael White
> > Cc: dspace-tech@lists.sourceforge.net
> > Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> >
> > Hi Mike,
> >
> > I could modify the stylesheet if you can test the changes. Please, file
> a new Jira
> > issue for this:
> > https://jira.duraspace.org/browse/DS
> >
> > On Tue, Oct 22, 2013 at 12:51 PM, Michael White <
> michael.wh...@stir.ac.uk>
> > wrote:
> > > - the output is not limited to only "Theses"
> >
> > What metadata field and value(s) in DSpace specifies that the item is a
> thesis?
> > (This will be a modification to
> > [dspace]/config/crosswalks/oai/xoai.xml)
> >
> > > - the supervisor (from dc.contributor.advisor) is mapping to
> > > dc.contributor instead of uketdterms:advisor
> > > - a number of other uketc_dc specific terms (e.g.
> > > "qualificationlevel", "qualificationname", etc) are not being included
> >
> > Please, provide the mapping of DSpace fields to uketd_dc fields (this
> will be
> > an update to uketd_dc.xsl).
> >

Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?

[Michael White]

Hi,

> Please, file a new Jira issue for this:

With apologies for the delay getting around to it, but I have now done this: 
https://jira.duraspace.org/i#browse/DS-1740 - this is my first time adding a 
JIRA ticket, so I hope everything is OK, but feel free to let me know or change 
anything if not :-)

> > > - the output is not limited to only "Theses"
> 
> What metadata field and value(s) in DSpace specifies that the item is a 
> thesis?

My understanding is that this is in dc.type - I'm currently liaising with a 
number of other DSpace users that participate in the EThOS service (the primary 
consumers of uketd_dc metadata) as there may well be more than one value - I'm 
hoping though that all the different variations will, at the very least, all 
contain the word "Thesis", so my first question is to ask if you know if it is 
possible to use pattern matching to carry out the filtering in xoai.xsl? I am 
intending to investigate this further, I just haven't got to it yet, but if 
anyone knows the answer it would be helpful at this stage!

In terms of dc.type - I've also noted an issue with this attribute - it looks 
to me like any dc.type or dc.type.* attributes are being concatenated into a 
single dc.type attribute before the data reaches the uketd_dc crosswalk (? 
Please correct me if I'm wrong!)  - I don't think this behaviour is correct in 
uketd_dc as there are a couple of qualified dc.type attributes that are mapped 
to their own uketd_dc elements, so I'm hoping that it will be possible to 
prevent this behaviour when generating uketd_dc OAI metadata (again, not had a 
chance to look myself yet, but will!)?

> Please, provide the mapping of DSpace fields to uketd_dc fields (this will be
> an update to uketd_dc.xsl).

I am currently working on this specification, which is nearly complete, and 
liaising with other institutions to ensure that the specified mapping is as 
generic as possible and so will work for the majority of institutions "out of 
the box" - alongside this I'm also creating a uketd_dc.xsl crosswalk that 
implements that specification, and, once complete, hopefully the folk from 
EThOS will be able to validate the output for us.

I'm hoping that all this will only take a couple of weeks to sort out (other 
work commitments allowing), but that may, of course, be a bit optimistic :-)

I hope that covers where I'm currently at and what I'm hoping to achieve, but 
of course, if anyone has any questions, comments, or concerns (or any pointers 
for any of the issues noted above), or if you are interested in participating 
in the specification/testing of this crosswalk (and haven't been in touch so 
far), then please don't hesitate to get back to me.

Regards,

Mike


Michael White 
eLearning Liaison and Development (eLD)
Information Services
S8, Library
University of Stirling 
Stirling SCOTLAND 
FK9 4LA 
Email: michael.wh...@stir.ac.uk 
Tel: +44 (0) 1786 466877 
Fax: +44 (0) 1786 466880
http://www.stir.ac.uk/is/staff/about/teams/aldt/#eld


> -Original Message-
> From: ivan.ma...@gmail.com [mailto:ivan.ma...@gmail.com] On Behalf Of
> helix84
> Sent: 22 October 2013 14:59
> To: Michael White
> Cc: dspace-tech@lists.sourceforge.net
> Subject: Re: [Dspace-tech] DSpace v3 and uketd_dc OAI?
> 
> Hi Mike,
> 
> I could modify the stylesheet if you can test the changes. Please, file a new 
> Jira
> issue for this:
> https://jira.duraspace.org/browse/DS
> 
> On Tue, Oct 22, 2013 at 12:51 PM, Michael White 
> wrote:
> > - the output is not limited to only "Theses"
> 
> What metadata field and value(s) in DSpace specifies that the item is a 
> thesis?
> (This will be a modification to
> [dspace]/config/crosswalks/oai/xoai.xml)
> 
> > - the supervisor (from dc.contributor.advisor) is mapping to
> > dc.contributor instead of uketdterms:advisor
> > - a number of other uketc_dc specific terms (e.g.
> > "qualificationlevel", "qualificationname", etc) are not being included
> 
> Please, provide the mapping of DSpace fields to uketd_dc fields (this will be
> an update to uketd_dc.xsl).
> 
> 
> Regards,
> ~~helix84
> 
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
> 


-- 
The University of Stirling has been ranked in the top 12 of UK universities for 
graduate employment*.
94% of our 2012 graduates were in work and/or further study within six months 
of graduation.
*The Telegraph
The University of Stirling is a charity registered in Scotland, number SC 
011159.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing lis

Re: [Dspace-tech] Customise Dspace Side News

[SUZUKI Keiji]

HI Sitali,

You use JSPUI, right? If so, you don't customize [dspace-src]/
dspace/config/news-side.html and run ant update. instead you
log in dspace as admin and  click "Administer" -> "Edit Nesw" ->
"Edit" of Sidebar News. Edit the news and click "Save". The edited
news is reflected immediately.

If your site is multilingual, switch language before editing news,
so that you can edit news in each language separately.

And you can edit [dspace]/config/news-side.html directly,
in this case the edited news is also reflected immediately.

Regards,
Keiji Suzuki,


2013/10/30 Chrispin Simasiku Sitali :
> Each time I customise the Side News, run ant update; the news is lost. Only
> the default site news remains. How can I edit the news so that the changes
> remain even after ant update.
> Thank you
>
> Sitali CS
>
> --
> Charles Lwanga College of Education,
> P. O. Box 660193,
> Monze,
> ZAMBIA.
>
> Mobile: +26 0979 869471
> SKYPE: Libsitali
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette



-- 
鈴木敬二＠江別市

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Sitemaps

[Sean Carte]

On 30 October 2013 10:29, Hilton Gibson  wrote:

> About DNS lookups, I normally trying caching the lookups using "nscd" on
> an Ubuntu server.
> The other culprit can be the campus DNS server.
> We have a "race" between the MS DNS servers and the internet DNS servers
> at the moment.
>

That's definitely worth investigating. Thanks, Hilton.

Sean
--
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

[Dspace-tech] Customise Dspace Side News

[Chrispin Simasiku Sitali]

Each time I customise the Side News, run ant update; the news is lost. Only
the default site news remains. How can I edit the news so that the changes
remain even after ant update.
Thank you

Sitali CS

-- 
Charles Lwanga College of Education,
P. O. Box 660193,
Monze,
ZAMBIA.

Mobile: +26 0979 869471
SKYPE: Libsitali
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

[Dspace-tech] Import items

[Stefanie Behnke]

Dear helix84,

 

sorry for not changing the subject in my last email.

 

I have tried to upload both items 009-013.pdf and 001-007.pdf and got error 
messages for both of them.

 

I have already exported an item, which I have uploaded before and manually set 
the permissions (using the jspui interface) to



 

After downloading the item the “contents” file contains:

113-116.pdf   bundle:ORIGINAL

 

but there is nothing said about the permissions.

So, how can I add permission to a bitstream when using the batch importer?

 

Thanking you in advance

Stefanie

 

 

-Ursprüngliche Nachricht-
Von: ivan.ma...@gmail.com [mailto:ivan.ma...@gmail.com] Im Auftrag von helix84
Gesendet: Dienstag, 29. Oktober 2013 22:27
An: Stefanie Behnke
Cc: dspace-tech
Betreff: Re: [Dspace-tech] Sitemaps

 

Hi Stefanie,

 

first, when starting a new topic on the mailing list, please start a new email 
thread.

 

 

On Tue, Oct 29, 2013 at 8:19 PM, Stefanie Behnke <  
s.beh...@online.de> wrote:

> I have created a file "contents" with:

> 009-013.pdf permissions:-r eg-member

> 

> but it does not work. I have got the error message:

> at java.lang.reflect.Method.invoke(Method.java:601)

> at

> org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:183)

> java.io.FileNotFoundException: /dspace/upload/test/001-007/001-007.pdf

> permissions:-r eg-member (No such file or directory)

 

You say your contents file contains "009-013.pdf", but the error complains 
about missing "001-007.pdf" file, which is a different file.

This doesn't look like a premission problem. Check your file names.

 

If you're uncertain about the format of the contents file, try exporting some 
item in the SAF format and look at the contents file.

Then you should be able to understand and create such file more easily than by 
following documentation.

 

 

Regards,

~~helix84

 

Compulsory reading: DSpace Mailing List Etiquette  
 
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

<>--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Sitemaps

[Hilton Gibson]

Hi Sean

About DNS lookups, I normally trying caching the lookups using "nscd" on an
Ubuntu server.
The other culprit can be the campus DNS server.
We have a "race" between the MS DNS servers and the internet DNS servers at
the moment.

Cheers

hg


On 30 October 2013 10:20, Sean Carte  wrote:

>
>
> On 29 October 2013 16:50, helix84  wrote:
>
>> On Tue, Oct 29, 2013 at 3:31 PM, Sean Carte  wrote:
>> > Thanks, Ivan. I've updated dspace.cfg, and regenerated the sitemaps.
>>
>> Sitemap looks good.
>>
>> Since you've likely been using the duplicate
>> http://ir.dut.ac.za/xmlui/ URL for a while and you might want to
>> migrate away from it without braking links, I suggest you use
>> mod_rewrite with a HTTP 302 code (permanent redirect) from all
>> http://ir.dut.ac.za/xmlui/* URLs to http://ir.dut.ac.za/*.
>>
>
> Thanks, Ivan, that's a good idea, but can I use mod_rewrite in conjunction
> with mod_proxy? My attempts seem to indicate not.
>
> With the following config in /var/www/.htaccess:
> RewriteEngine on
> RewriteRule ^xmlui / [R=302,L]
>
> /etc/apache2/sites-enabled/000-default:
> s/AllowOverride None/AllowOverride All/
>
> The redirection works if mod_proxy and friends are disabled, but otherwise
> nothing.
>
> The handle redirect still takes over 60 seconds and takes me to
>> http://ir.dut.ac.za:8080/xmlui/... Did you try restarting your local
>> handle server? It might not solve the delay, but I think it should
>> change the target URL to your dspace.url.
>>
>> I restarted handled. It didn't solve the delay, but it did change the
> target URL.
>
> It's always taken a while to resolve handle.net links. I've always
> assumed that was just how long it took. I get a reasonable response times
> from pings to hdl.handle.net:
>
> PING hdl.handle.net (38.100.138.165) 56(84) bytes of data.
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=1 ttl=47
> time=303 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=2 ttl=47
> time=296 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=3 ttl=47
> time=303 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=4 ttl=47
> time=303 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=5 ttl=47
> time=295 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=6 ttl=47
> time=295 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=7 ttl=47
> time=297 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=8 ttl=47
> time=295 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=9 ttl=47
> time=295 ms
> 64 bytes from test165.handle.net (38.100.138.165): icmp_req=10 ttl=47
> time=303 ms
> ^C
> --- hdl.handle.net ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 9012ms
> rtt min/avg/max/mdev = 295.513/298.927/303.347/3.562 ms
>
> It would be great if I could find a way to speed up the resolution of
> handle links. Any ideas?
>
> Sean
> --
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> ___
> DSpace-tech mailing list
> DSpace-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>



-- 
*Hilton Gibson*
Ubuntu Linux Systems Administrator
JS Gericke Library
Room 1025D
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758
http://library.sun.ac.za
http://za.linkedin.com/in/hiltongibson
http://staff.lib.sun.ac.za/~hgibson/docs/cv/cv.html
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Sitemaps

[Sean Carte]

On 29 October 2013 16:50, helix84  wrote:

> On Tue, Oct 29, 2013 at 3:31 PM, Sean Carte  wrote:
> > Thanks, Ivan. I've updated dspace.cfg, and regenerated the sitemaps.
>
> Sitemap looks good.
>
> Since you've likely been using the duplicate
> http://ir.dut.ac.za/xmlui/ URL for a while and you might want to
> migrate away from it without braking links, I suggest you use
> mod_rewrite with a HTTP 302 code (permanent redirect) from all
> http://ir.dut.ac.za/xmlui/* URLs to http://ir.dut.ac.za/*.
>

Thanks, Ivan, that's a good idea, but can I use mod_rewrite in conjunction
with mod_proxy? My attempts seem to indicate not.

With the following config in /var/www/.htaccess:
RewriteEngine on
RewriteRule ^xmlui / [R=302,L]

/etc/apache2/sites-enabled/000-default:
s/AllowOverride None/AllowOverride All/

The redirection works if mod_proxy and friends are disabled, but otherwise
nothing.

The handle redirect still takes over 60 seconds and takes me to
> http://ir.dut.ac.za:8080/xmlui/... Did you try restarting your local
> handle server? It might not solve the delay, but I think it should
> change the target URL to your dspace.url.
>
> I restarted handled. It didn't solve the delay, but it did change the
target URL.

It's always taken a while to resolve handle.net links. I've always assumed
that was just how long it took. I get a reasonable response times from
pings to hdl.handle.net:

PING hdl.handle.net (38.100.138.165) 56(84) bytes of data.
64 bytes from test165.handle.net (38.100.138.165): icmp_req=1 ttl=47
time=303 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=2 ttl=47
time=296 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=3 ttl=47
time=303 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=4 ttl=47
time=303 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=5 ttl=47
time=295 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=6 ttl=47
time=295 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=7 ttl=47
time=297 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=8 ttl=47
time=295 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=9 ttl=47
time=295 ms
64 bytes from test165.handle.net (38.100.138.165): icmp_req=10 ttl=47
time=303 ms
^C
--- hdl.handle.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 295.513/298.927/303.347/3.562 ms

It would be great if I could find a way to speed up the resolution of
handle links. Any ideas?

Sean
--
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette