[dspace-tech] SWORDv2 configuration error- Help!

[tuf04742]

We're attempting to enable the SWORDv2 endpoint in our DSpace instance for 
use in a DSpace-Symplectic Elements Repository Tools 2 integration.  The 
service document gives this error: "Unable to recognise URL as a valid 
service document:..." 

Does anyone have any insight into what could be causing this error?  

Here's the full message: 

http://purl.org/net/sword/terms/"; href="
http://www.dspace.org/ns/sword/2.0/errors/BadUrl";>
http://www.w3.org/2005/Atom";>ERROR
http://www.w3.org/2005/Atom";>2018-08-22T17:05:38Z

http://www.w3.org/2005/Atom"; uri="
http://www.dspace.org/ns/sword/2.0/"; version="2.0">[EmailRedacted]

Processing failed
http://www.w3.org/2005/Atom";>
Unable to recognise URL as a valid service document: 
http://155.247.166.104:8080/swordv2/servicedocument


org.swordapp.server.SwordError: Unable to recognise URL as a valid service 
document: http://155.247.166.104:8080/swordv2/servicedocument at 
org.dspace.sword2.SwordUrlManager.extractDSpaceObject(SwordUrlManager.java:323) 
at 
org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:169)
 
at 
org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:74)
 
at org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56) 
at 
org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
 
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)
 
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
 
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
 
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) 
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) 
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
 
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) 
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)
 
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
 
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 
at java.lang.Thread.run(Thread.java:748)

http://www.w3.org/2005/Atom"; rel="alternate" type="
text/html" href="http://localhost:8080/contact"/>


Thanks for any help you can give us!  

-GG

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] SWORDv2 configuration error- Help!

[tuf04742]

Andrea- 

Thank you so much for this tip!  Uncommenting and standardizing the 
servicedocument.url property, plus one other minor change, fixed the 
problem.  

Keep up the good work!  

-GG


On Wednesday, August 22, 2018 at 5:41:26 PM UTC-4, Andrea Schweer wrote:
>
> And further to that (having tripped over this myself about five minutes 
> ago) - the url property in that file doesn't carry over to the 
> collection.url and servicedocument.url properties, so if you use a non 
> standard "url" value then (as stated in the comments of the file) you'll 
> have to adjust those two properties as well.
>
> cheers,
> Andrea
>
> On Thu, 23 Aug 2018 at 09:23, Andrea Schweer  > wrote:
>
>> Hi,
>>
>> check what you have configured as the service document URL - probably in 
>> [dspace]/config/modules/swordv2-server.cfg. It's the first property in that 
>> file "url". The default is {dspace.url}/swordv2 and the base URL you use in 
>> your sword deposit must match that exactly.
>>
>> cheers,
>> Andrea
>>
>> On Thu, 23 Aug 2018 at 09:21, > wrote:
>>
>>>
>>>
>>> We're attempting to enable the SWORDv2 endpoint in our DSpace instance 
>>> for use in a DSpace-Symplectic Elements Repository Tools 2 integration.  
>>> The service document gives this error: "Unable to recognise URL as a 
>>> valid service document:..." 
>>>
>>> Does anyone have any insight into what could be causing this error?  
>>>
>>> Here's the full message: 
>>>
>>> http://purl.org/net/sword/terms/"; href="
>>> http://www.dspace.org/ns/sword/2.0/errors/BadUrl";>
>>> http://www.w3.org/2005/Atom";>ERROR
>>> http://www.w3.org/2005/Atom";>
>>> 2018-08-22T17:05:38Z
>>> http://www.w3.org/2005/Atom"; uri="
>>> http://www.dspace.org/ns/sword/2.0/"; version="2.0">[EmailRedacted]
>>> 
>>> Processing failed
>>> http://www.w3.org/2005/Atom";>
>>> Unable to recognise URL as a valid service document: 
>>> http://155.247.166.104:8080/swordv2/servicedocument
>>> 
>>> 
>>> org.swordapp.server.SwordError: Unable to recognise URL as a valid 
>>> service document: http://155.247.166.104:8080/swordv2/servicedocument 
>>> at 
>>> org.dspace.sword2.SwordUrlManager.extractDSpaceObject(SwordUrlManager.java:323)
>>>  
>>> at 
>>> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:169)
>>>  
>>> at 
>>> org.dspace.sword2.ServiceDocumentManagerDSpace.getServiceDocument(ServiceDocumentManagerDSpace.java:74)
>>>  
>>> at org.swordapp.server.ServiceDocumentAPI.get(ServiceDocumentAPI.java:56) 
>>> at 
>>> org.swordapp.server.servlets.ServiceDocumentServletDefault.doGet(ServiceDocumentServletDefault.java:32)
>>>  
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:624) at 
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at 
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>>>  
>>> at 
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>>  
>>> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 
>>> at 
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>>  
>>> at 
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>>  
>>> at 
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)
>>>  
>>> at 
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
>>>  
>>> at 
>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
>>>  
>>> at 
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
>>>  
>>> at 
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>>>  
>>> at 
>>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) 
>>> at 
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>>>  
>>> at 
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) 
>>> at 
>>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)
>>>  
>>> at 
>>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
>>>  
>>> at 
>>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
>>>  
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>  
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>  
>>> at 
>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>>  
>>> at java.lang.Thread.run(Thread.java:748)
>>> 
>>> http://www.w3.org/2005/Atom"; rel="alternate" type
>>> ="text/html" href="http://localhost:8080/contact"/>
>>> 
>>>
>>> Thanks for any help you can give us!  
>>>
>>> -GG
>>>
>>> -- 
>>> All messages to this mailing list should adhere to the DuraSpace Code o

[dspace-tech] URIs generating with 'http://localhost:8080' as root

[tuf04742]

Hello! 

We are very new to DSpace and operating on a limited technical staff.  We 
have our DSpace up and running, but are running into a problem:  

The URIs are generating with "http://localhost:8080 
/xmlui"

http://localhost:8080/xmlui/handle/123456789/27
 
How can this problem be fixed?  Would this be done through the config file 
or some other way.  

Thank you in advance for any help you can give us!  

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Any way to switch item collection during metadata review (workflow tasks)

[tuf04742]

All-  

At our institution we'd like to set up a workflow where items are ingested 
into a single 'review' DSpace collection (from Symplectic Elements), then 
moved into another collection by a metadata reviewer as they're approved.  

Is there any way to do this through the Item submission interface, or would 
this move have to be accomplished after each item is approved, through the 
UI?

Thank you for your help!  

-GG

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Example EPerson schema? Necessary EPerson schema fields?

[tuf04742]

Hey everyone- 

Our DSpace instance was initially set up by someone no longer employed at 
our institution.  For whatever reason the EPerson schema reads like this:  

194 eperson.javascript:alert(10379).1234 

 
1234
370 eperson.language 

 
3 eperson.lastname.1234 

 
1234
2 eperson.lastname 

 
149 eperson.ls.1234 

 
1234
363 eperson.password.1234 

 
362 eperson.password 

 
372 eperson.phone 

 
139 eperson.ProbePhishing.1234 

 
1234
183 eperson.alert(10339).1234 

 
1234
202 eperson.alert(4224).1234 

 
1234
And so on...  

To do certain tasks we've been having to add fields to this.  For example, 
to add a new user through the UI we had to add 'eperson.phone.null' to keep 
it from throwing the following error:  "bad_dublin_core 
schema=eperson.phone.null. Metadata field does not exist!"  We'd like to 
proactively create these fields. Is there an example out-of-the-box eperson 
schema we could refer to on the web?  We wern't able to locate one.  
Alternately, would someone be willing to send us a list of fields that 
should be present in an un-customized eperson schema, or to copy and paste 
your schema into a document we could look over?  This would be much 
appreciated!  

A second question:  Both 'eperson.lastname.1234' and 'eperson.lastname' 
give an 'in use' error when one tries to delete them ("Metadata field 
eperson_lastname_1234 cannot be deleted as it is currently used by one or 
more objects.").  Most of the ...1234 fields can be deleted, meaning the 
system isn't using them.  Does anyone have any insight into why the 
'eperson.lastname.1234' would be in use?  

Thank you so much for your help! 

-GG



-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Mapping ETD metadata sent from ProQuest to DSpace via SWORDv1

[tuf04742]

Group-  

We've configured our SWORDv1 end and ProQuest has successfully delivered to 
our repository through it.  ProQuest support is saying that mapping is done 
DSpace-side, rather than on their end, but I'm unclear on how this works.  
Could someone with more experience on the ProQuest->DSpace workflow start 
me down the right path?  

Would we be creating an XML/.XSL map along the lines of the file I'm 
attaching?  Or would we need to create another type of document?  How would 
this be added to DSpace/SWORD?  

Thank you so much for your help!  

-Gabe Galson

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


diss-to-dc (1).xsl
Description: XML document

[dspace-tech] Re: Mapping ETD metadata sent from ProQuest to DSpace via SWORDv1

[tuf04742]

To clarify what I mean by mapping, I mean mapping ProQuest ETD Admin xml 
field 'X' to DSpace dublin core field 'Y'.How would we get 
"//DISS_description/DISS_categorization/DISS_category/DISS_cat_desc" to map 
to "dc.subject"

Thanks!

-Gabe


On Friday, November 30, 2018 at 1:38:25 PM UTC-5, tuf0...@temple.edu wrote:
>
> Group-  
>
> We've configured our SWORDv1 end and ProQuest has successfully delivered 
> to our repository through it.  ProQuest support is saying that mapping is 
> done DSpace-side, rather than on their end, but I'm unclear on how this 
> works.  Could someone with more experience on the ProQuest->DSpace workflow 
> start me down the right path?  
>
> Would we be creating an XML/.XSL map along the lines of the file I'm 
> attaching?  Or would we need to create another type of document?  How would 
> this be added to DSpace/SWORD?  
>
> Thank you so much for your help!  
>
> -Gabe Galson
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Mapping ETD metadata sent from ProQuest to DSpace via SWORDv1

[tuf04742]

Checking one more time.  Does anyone have experience using SWORD to 
crosswalk metadata?  

-Gabe

On Friday, November 30, 2018 at 1:43:54 PM UTC-5, tuf0...@temple.edu wrote:
>
> To clarify what I mean by mapping, I mean mapping ProQuest ETD Admin xml 
> field 'X' to DSpace dublin core field 'Y'.How would we get 
> "//DISS_description/DISS_categorization/DISS_category/DISS_cat_desc" to map 
> to "dc.subject"
>
> Thanks!
>
> -Gabe
>
>
> On Friday, November 30, 2018 at 1:38:25 PM UTC-5, tuf0...@temple.edu 
> wrote:
>>
>> Group-  
>>
>> We've configured our SWORDv1 end and ProQuest has successfully delivered 
>> to our repository through it.  ProQuest support is saying that mapping is 
>> done DSpace-side, rather than on their end, but I'm unclear on how this 
>> works.  Could someone with more experience on the ProQuest->DSpace workflow 
>> start me down the right path?  
>>
>> Would we be creating an XML/.XSL map along the lines of the file I'm 
>> attaching?  Or would we need to create another type of document?  How would 
>> this be added to DSpace/SWORD?  
>>
>> Thank you so much for your help!  
>>
>> -Gabe Galson
>>
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Re: Mapping ETD metadata sent from ProQuest to DSpace via SWORDv1

[tuf04742]

Tim-  

Thank you so much!!  This is just the overview I needed to move forward.  
Keep up the good work!

-Gabe

On Thursday, December 13, 2018 at 2:04:19 PM UTC-5, Tim Donohue wrote:
>
> Hi Gabe,
>
> I don't have direct experience with mapping *ProQuest* fields into DSpace 
> fields.  However, I do have a few possible clues on how DSpace SWORD does 
> metadata mapping that could help you out here.
>
> The SWORD (v1) interface just uses DSpace's built in "METS" Ingester by 
> default for all imports (via SWORD).  That's in this configuration in 
> sword-server.cfg: 
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/sword-server.cfg#L21
>
> The default "METS" ingester uses a specific Crosswalk, based on the 
> "mdtype" specified in the METS metadata. Those are configured in your 
> dspace.cfg here:
>
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L563-L574
>  
>
> For SWORD, the recommended format is often EPDCX (EPrints DC XML), but 
> whatever format is specified in the METS is the format that DSpace will try 
> to crosswalk.  If the format is specified as EPDCX, then DSpace will use 
> this configuration:
>
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/dspace.cfg#L438
>  
>
> (If you want to see what a SWORD METS package with EPDCX specified as the 
> "mdtype", we have an example that is distributed with DSpace at: 
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-sword/example/example.zip
> )
>
> That configuration tells DSpace that anything claiming to be "EPDCX" 
> should be mapped using the XSLT stylesheet at 
> [dspace]/config/crosswalks/sword-swap-ingest.xsl.  That specific XSLT 
> stylesheet is what translates EPDCX to DSpace's internal dublin core 
> fields: 
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/crosswalks/sword-swap-ingest.xsl
>  
>
> This entire process is somewhat documented in the SWORD configuration docs 
> at: 
> https://wiki.duraspace.org/dsdoc6x/using-dspace/ingesting-content-and-metadata/swordv1-server
>  (You'll 
> see all these configurations mentioned there.)
>
> So, if you wanted to change this to map ProQuest to DSpace, you'd first 
> want to see what these ProQuest METS files look like (and the "mdtype" they 
> report).  Then, you can add in a *new* set of these configurations to map 
> that "mdtype" to an XSLT mapper.  
>
> So, assuming ProQuest's files say something like "MDTYPE='PROQUEST'" (or 
> "MDTYPE='OTHER' OTHERMDTYPE='PROQUEST'), you should be able to do something 
> like this:
>
> mets.submission.crosswalk.PROQUEST = PROQUEST
> crosswalk.submission.PROQUEST.stylesheet = 
> crosswalks/my-proquest-mapper.xsl  
>
> Then, you'd just need to be sure your "my-proquest-mapper.xsl" is able to 
> map all the necessary Proquest metadata fields into DSpace dublin core 
> (similar to how "sword-swap-ingest.xsl" does).
>
> So, maybe that'd give you some clues on how you could get started!
>
> Tim
>
>
>
> On Thu, Dec 13, 2018 at 12:30 PM > wrote:
>
>> Checking one more time.  Does anyone have experience using SWORD to 
>> crosswalk metadata?  
>>
>> -Gabe
>>
>>
>> On Friday, November 30, 2018 at 1:43:54 PM UTC-5, tuf0...@temple.edu 
>> wrote:
>>>
>>> To clarify what I mean by mapping, I mean mapping ProQuest ETD Admin xml 
>>> field 'X' to DSpace dublin core field 'Y'.How would we get 
>>> "//DISS_description/DISS_categorization/DISS_category/DISS_cat_desc" to map 
>>> to "dc.subject"
>>>
>>> Thanks!
>>>
>>> -Gabe
>>>
>>>
>>> On Friday, November 30, 2018 at 1:38:25 PM UTC-5, tuf0...@temple.edu 
>>> wrote:

 Group-  

 We've configured our SWORDv1 end and ProQuest has successfully 
 delivered to our repository through it.  ProQuest support is saying that 
 mapping is done DSpace-side, rather than on their end, but I'm unclear on 
 how this works.  Could someone with more experience on the 
 ProQuest->DSpace 
 workflow start me down the right path?  

 Would we be creating an XML/.XSL map along the lines of the file I'm 
 attaching?  Or would we need to create another type of document?  How 
 would 
 this be added to DSpace/SWORD?  

 Thank you so much for your help!  

 -Gabe Galson

>>> -- 
>> All messages to this mailing list should adhere to the DuraSpace Code of 
>> Conduct: https://duraspace.org/about/policies/code-of-conduct/
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "DSpace Technical Support" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to dspace-tech...@googlegroups.com .
>> To post to this group, send email to dspac...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/dspace-tech.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>

-- 
All mess

[dspace-tech] A way to alter metadata values for display?

[tuf04742]

Group-  

Is there a straightforward way to hide the actual values contained in a 
field, while displaying translated or crosswalked versions of those 
values?  We'd like to automatically translate two letter language codes 
into text: the language field would contain the value 'en' but display the 
value 'english'.  

Can anyone suggest a procedure for accomplishing this?  

Thank you in advance for your help!  We are just getting started with 
DSpace.  

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] A way to alter metadata values for display?

[tuf04742]

Terry-  

We are using DSpace 6.2 with XMLUI.  We haven't selected a theme, but are 
interested in using one down the line, and it would be great to know how 
our selection would affect this.  

Thank you so much for your help!  

-Gabe

On Thursday, January 10, 2019 at 9:46:44 AM UTC-5, Wenz, Armin wrote:
>
> Hi, 
>
> we want to accomplish the same task with multiple values (e.g. language 
> codes, ddc, document types) 
> We are using DSpace 6.3 with JSPUI. 
>
> Would be great if you can suggest a procedure or point me/us to a 
> document describing a solution. 
>
> Thanks 
>
>
> Am Mittwoch, den 09.01.2019, 15:30 -0800 schrieb Terry Brady: 
> > Gabe,  
> > 
> > Please provide a couple additional bits of information. 
> > 
> > - Which version of DSpace are you using? 
> > - Which UI do you use?  XMLUI or JSPUI? 
> > - If you are running XMLUI, what theme do you use? 
> > 
> > Terry 
> > 
> > On Wed, Jan 9, 2019 at 1:38 PM > 
> wrote: 
> > > Group-   
> > > 
> > > Is there a straightforward way to hide the actual values contained 
> > > in a field, while displaying translated or crosswalked versions of 
> > > those values?  We'd like to automatically translate two letter 
> > > language codes into text: the language field would contain the 
> > > value 'en' but display the value 'english'.   
> > > 
> > > Can anyone suggest a procedure for accomplishing this?   
> > > 
> > > Thank you in advance for your help!  We are just getting started 
> > > with DSpace.   
> > > 
> > > -Gabe 
> > > --  
> > > All messages to this mailing list should adhere to the DuraSpace 
> > > Code of Conduct: https://duraspace.org/about/policies/code-of-condu 
> > > ct/ 
> > > ---  
> > > You received this message because you are subscribed to the Google 
> > > Groups "DSpace Technical Support" group. 
> > > To unsubscribe from this group and stop receiving emails from it, 
> > > send an email to dspace-tech...@googlegroups.com . 
> > > To post to this group, send email to dspac...@googlegroups.com 
> . 
> > > Visit this group at https://groups.google.com/group/dspace-tech. 
> > > For more options, visit https://groups.google.com/d/optout. 
> > > 
> > 
> > 
> > --  
> > Terry Brady 
> > Applications Programmer Analyst 
> > Georgetown University Library Information Technology 
> > https://github.com/terrywbrady/info 
> > 425-298-5498 (Seattle, WA) 
>
> -- 
>
> Armin Wenz 
> Universitätsbibliothek Mainz 
> Leitung Bibliotheksanwendungen 
> Jakob-Welder-Weg 12 
> 55128 Mainz 
> Tel.: +49 6131 39-29830 
> http://www.ub.uni-mainz.de 
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Institutions using SWORDv1 to ingest from ProQuest?

[tuf04742]

Hey Group-  

We're implementing a DSpace-based IR at my institution, and are interested 
in ingesting from ProQuest's ETD admin tool via the SWORDv1 protocol.  
Could anyone in this group direct us to any other institutions using such a 
workflow?  So far we haven't been able to turn up any! 

Thank you in advance for your help!

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] ORCID integration and DSpace versions- will it work pre-6.3?

[tuf04742]

Group-  

Will the procedure described in DSpace's ORCID integration wiki page 
 work for 
version 6.2, or only version 6.3?  I've heard that only 6.3 will work, 
since ORCID's version 1 API was depreciated.  At the same time, I see no 
mention of this in the documentation so I wanted to confirm via the 
community.  

Thank you for any insight you can provide! 

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Auto populating a field with MIME types and/or file extensions pulled from 'provenance'?

[tuf04742]

Group-  

At my institution we're interested in populating a field with file 
extensions pulled from the automatically generated 'provenance' data.  If 
possible, we'd also like to translate these into controlled MIME type 
values found in this list 
.  

For example, from this autogenerated 'dc.description.provenance' field 
value
"
Made available in DSpace on 2019-01-23T14:28:53Z (GMT). No. of bitstreams: 
2 sword-2019-01-23T09:27:28.original.xml: 130 bytes, checksum: 
43dce2ea292b96aeb7545ed6c2a2cce8 (MD5) dspace-XwalkOut-map (11).xml: 6962 
bytes, checksum: 2961d1467ed455e4bd9e3780612b779d (MD5) Previous issue 
date: 2005-05-01
"
...we'd want to 
1) extract ".xml" and put it in other 'file extension' field.  
2) Auto-translate this into 'application/atom+xml', as in the mime type 
table .  I imagine this 
table would have to be put in a back end document as a crosswalk table, but 
I'm not sure which this would be, or how exactly this would work.  

Any help the community can provide would be much appreciated!  Just pulling 
the extensions would be a great start.  

Thanks!

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Auto populating a field with MIME types and/or file extensions pulled from 'provenance'?

[tuf04742]

Andrea-

We're interested in a way to pull out just the file extension from the 
auto-generated field you've mentioned and put it programmatically in 
another field.  Do you know of a way to do this?  

Thank you so much for the help you've already provided!

-Gabe



On Monday, January 28, 2019 at 3:48:24 PM UTC-5, tuf0...@temple.edu wrote:
>
> Group-  
>
> At my institution we're interested in populating a field with file 
> extensions pulled from the automatically generated 'provenance' data.  If 
> possible, we'd also like to translate these into controlled MIME type 
> values found in this list 
> .  
>
> For example, from this autogenerated 'dc.description.provenance' field 
> value
> "
> Made available in DSpace on 2019-01-23T14:28:53Z (GMT). No. of bitstreams: 
> 2 sword-2019-01-23T09:27:28.original.xml: 130 bytes, checksum: 
> 43dce2ea292b96aeb7545ed6c2a2cce8 (MD5) dspace-XwalkOut-map (11).xml: 6962 
> bytes, checksum: 2961d1467ed455e4bd9e3780612b779d (MD5) Previous issue 
> date: 2005-05-01
> "
> ...we'd want to 
> 1) extract ".xml" and put it in other 'file extension' field.  
> 2) Auto-translate this into 'application/atom+xml', as in the mime type 
> table .  I imagine 
> this table would have to be put in a back end document as a crosswalk 
> table, but I'm not sure which this would be, or how exactly this would 
> work.  
>
> Any help the community can provide would be much appreciated!  Just 
> pulling the extensions would be a great start.  
>
> Thanks!
>
> -Gabe
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Auto populating a field with MIME types and/or file extensions pulled from 'provenance'?

[tuf04742]

Andrea-  

This is so helpful.  Thank you!!

-Gabe

On Monday, January 28, 2019 at 3:48:24 PM UTC-5, tuf0...@temple.edu wrote:
>
> Group-  
>
> At my institution we're interested in populating a field with file 
> extensions pulled from the automatically generated 'provenance' data.  If 
> possible, we'd also like to translate these into controlled MIME type 
> values found in this list 
> .  
>
> For example, from this autogenerated 'dc.description.provenance' field 
> value
> "
> Made available in DSpace on 2019-01-23T14:28:53Z (GMT). No. of bitstreams: 
> 2 sword-2019-01-23T09:27:28.original.xml: 130 bytes, checksum: 
> 43dce2ea292b96aeb7545ed6c2a2cce8 (MD5) dspace-XwalkOut-map (11).xml: 6962 
> bytes, checksum: 2961d1467ed455e4bd9e3780612b779d (MD5) Previous issue 
> date: 2005-05-01
> "
> ...we'd want to 
> 1) extract ".xml" and put it in other 'file extension' field.  
> 2) Auto-translate this into 'application/atom+xml', as in the mime type 
> table .  I imagine 
> this table would have to be put in a back end document as a crosswalk 
> table, but I'm not sure which this would be, or how exactly this would 
> work.  
>
> Any help the community can provide would be much appreciated!  Just 
> pulling the extensions would be a great start.  
>
> Thanks!
>
> -Gabe
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: citation generation

[tuf04742]

Here is the relevant documentation:  

https://wiki.duraspace.org/display/DSPACE/Citation+Generation



On Thursday, February 21, 2019 at 8:37:44 AM UTC-5, Muthuswamy N wrote:
>
> Hi, The link you have sent seems to lead to Dspace servlet engine. How is 
> this related to citation generation? Please help clarify. 
>
> On Thursday, February 21, 2019 at 5:52:14 AM UTC+5:30, Ousman Mohammed 
> wrote:
>>
>>
>>
>> On Wednesday, February 20, 2019 at 6:18:08 PM UTC+3, Muthuswamy N wrote:
>>>
>>> Is there is step by step instruction to enable citation generation in 
>>> dspace 6.3?
>>> Grateful if anyone can point me to related documentation. 
>>>
>>
>>
>> https://wiki.duraspace.org/display/DSDOC6x/Installing+DSpace#InstallingDSpace-ServletEngine(ApacheTomcat7orlater,Jetty,CauchoResinorequivalent)
>>   
>> 
>>
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Strategies for granting anonymous, uni-affiliated users access to the submission form via Shibboleth

[tuf04742]

Group-  

At my University we'd like to take users directly from a Shibboleth 
authentication screen to the first page of the Submission User Interface 
(pictured in screenshot).  We'd also like to, if possible:

--Do this for three separate submission forms, one leading to a 'data' 
community, one for an 'articles' community, and a third for an 'ETD' 
community.  
--Be able to put a 'Submit to our IR!' link on outside webpages.  This will 
take users to a Shib authentication page, then directly to the Submission 
user interface

What are some workable strategies for doing all this?  Thank you so much 
for your help!!

In other words, we want them to go directly from the Shib login screen to 
here:  

[image: Screen Shot 2019-03-06 at 4.10.41 PM.png] 
Thanks!
-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Strategies for granting anonymous, uni-affiliated users access to the submission form via Shibboleth

[tuf04742]

Does anyone have any leads on this?  

On Wednesday, March 6, 2019 at 4:18:00 PM UTC-5, tuf0...@temple.edu wrote:
>
> Group-  
>
> At my University we'd like to take users directly from a Shibboleth 
> authentication screen to the first page of the Submission User Interface 
> (pictured in screenshot).  We'd also like to, if possible:
>
> --Do this for three separate submission forms, one leading to a 'data' 
> community, one for an 'articles' community, and a third for an 'ETD' 
> community.  
> --Be able to put a 'Submit to our IR!' link on outside webpages.  This 
> will take users to a Shib authentication page, then directly to the 
> Submission user interface
>
> What are some workable strategies for doing all this?  Thank you so much 
> for your help!!
>
> In other words, we want them to go directly from the Shib login screen to 
> here:  
>
> [image: Screen Shot 2019-03-06 at 4.10.41 PM.png]
> Thanks!
> -Gabe
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Outputting Qualified Dublin Core through DSpace's OAI- proper system configuration?

[tuf04742]

Group-  

We're configuring our DSpace and want to be able to output qualified Dublin 
Core through OAI.  Would someone be able to give us an overview of how the 
system must be configured to do this?  

Should be putting field values exclusively in the 'dcterms' schema fields?  
Or, should we be entering our field values into the 'dc' fields, but then 
defining a crosswalk to QDC via the 'QDC.properties' crosswalk 

?

How must oai.cfg be adjusted to allow for the export of QDC?  Would this be 
done soley through this oai.cfg  
document,
 
or must other changes be made also?  

Forgive our inexperience, and thank you for your help!  

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Outputting Qualified Dublin Core through DSpace's OAI- proper system configuration?

[tuf04742]

Group-  

We're configuring our DSpace and want to be able to output qualified Dublin 
Core through OAI.  Would someone be able to give us an overview of how the 
system must be configured to do this?  

Should be putting field values exclusively in the 'dcterms' schema fields?  
Or, should we be entering our field values into the 'dc' fields, but then 
defining a crosswalk to QDC via the 'QDC.properties' crosswalk 

?

How must oai.cfg be adjusted to allow for the export of QDC?  Would this be 
done soley through this oai.cfg  
document,
 
or must other changes be made also?  

Forgive our inexperience, and thank you for your help!  

-Gabe

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Outputting Qualified Dublin Core through DSpace's OAI- proper system configuration?

[tuf04742]

Does anyone have any insight into this?  Thank you in advance for your help!

On Monday, April 8, 2019 at 11:30:00 AM UTC-4, tuf0...@temple.edu wrote:
>
> Group-  
>
> We're configuring our DSpace and want to be able to output qualified 
> Dublin Core through OAI.  Would someone be able to give us an overview of 
> how the system must be configured to do this?  
>
> Should be putting field values exclusively in the 'dcterms' schema 
> fields?  Or, should we be entering our field values into the 'dc' fields, 
> but then defining a crosswalk to QDC via the 'QDC.properties' crosswalk 
> 
> ?
>
> How must oai.cfg be adjusted to allow for the export of QDC?  Would this 
> be done soley through this oai.cfg  
> document,
>  
> or must other changes be made also?  
>
> Forgive our inexperience, and thank you for your help!  
>
> -Gabe
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Integration with LCNAF via authority control- is it working??

[tuf04742]

Group-  

At my uni we'd like to Integrate our DSpace wtih Library of Congress Name 
Authority File (LCNAF), as described on this configuration how-to page 
 

See this section:  

Property:

lcname.url

Example Value:

lcname.url = http://alcme.oclc.org/srw/search/lcnaf_

Informational Note:

Location (URL) of the Library of Congress Name Service


*Our question is, *is the ' http://alcme.oclc.org/srw/search/lcnaf 'endpoint 
working or not?  If you click through to the site it indicates that it 
hasn't been updated since 2015, but maybe they just mean the site 
interface.  

This ticket indicates that it was down 
https://jira.duraspace.org/browse/DS-557?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&showAll=true

-GG

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Integration with LCNAF via authority control- is it working??

[tuf04742]

Does anyone have any insight into this?  Checking back in with the group.  

On Thursday, May 2, 2019 at 12:59:39 PM UTC-4, tuf0...@temple.edu wrote:
>
> Group-  
>
> At my uni we'd like to Integrate our DSpace wtih Library of Congress Name 
> Authority File (LCNAF), as described on this configuration how-to page 
>  
>
> See this section:  
>
> Property:
>
> lcname.url
>
> Example Value:
>
> lcname.url = http://alcme.oclc.org/srw/search/lcnaf_
>
> Informational Note:
>
> Location (URL) of the Library of Congress Name Service
>
>
> *Our question is, *is the ' http://alcme.oclc.org/srw/search/lcnaf 'endpoint 
> working or not?  If you click through to the site it indicates that it 
> hasn't been updated since 2015, but maybe they just mean the site 
> interface.  
>
> This ticket indicates that it was down 
>
> https://jira.duraspace.org/browse/DS-557?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&showAll=true
>
> -GG
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/9fb47e97-4ec3-432d-a3f7-eaae46680768%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.