[Dspace-devel] [DuraSpace JIRA] (DS-1755) Manual submission in "Bibliographic import and lookup in Submission" does not function
Title: Message Title Andrea Bollini closed an issue as Fixed merged here https://github.com/DSpace/DSpace/commit/1da709185121c28b9f2142e5b297f33e3e293d6d DSpace / DS-1755 Manual submission in "Bibliographic import and lookup in Submission" does not function Change By: Andrea Bollini Resolution: Fixed Fix Version/s: 4.0 Assignee: Andrea Bollini Status: Received Closed Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- Novembe
[Dspace-devel] [DuraSpace JIRA] (DS-1775) Increase robustness of SolrServiceImpl date format guessing
Title: Message Title Bram Luyten (@mire) created an issue DSpace / DS-1775 Increase robustness of SolrServiceImpl date format guessing Issue Type: Improvement Assignee: Unassigned Components: Discovery Created: 08/Nov/13 1:53 PM Priority: Minor Reporter: Bram Luyten (@mire) When looking at: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/discovery/SolrServiceImpl.java#L1439 It seems like the date is guessed purely on String length. Maybe this date guessing can be made more robust by doing proper regex matching, like the example here: http://stackoverflow.com/a/3390252 Note that this example code also requires some additional matches to add timezone support. Add Comment
[Dspace-devel] [DuraSpace JIRA] (DS-1740) XOAI producing invalid uketd_dc OAI-PMH output
Title: Message Title Michael White commented on an issue Re: XOAI producing invalid uketd_dc OAI-PMH output > once you have the revised xoai.xml and uketd_dc.xsl could you provide them as a pull request against the DSpace github repository? OK, the uketd_dc XSLT crosswalk is now finished and successfully tested (in my v3.1 DEV system), as are the required changes to xoai.xml. I'm more than happy to "provide them as a pull request against the DSpace github repository", but I've not used github (or anything similar before), so could do with some pointers as to how I do this. I've signed up on github and had a poke about/read some docs but don't want to do the wrong thing and make a mess! So, specifically, do I need to "fork the repository"? And, if I do, what happens next! Apologies for the newbie questions, but I'd prefer to do it right, rather than just guess :-) Cheers, Mike Add Comment DSpace / DS-1740 XOAI producing invalid uketd_dc OAI-PMH output The new XOAI mechanism for generating OAI-PMH data (added in DSpace v3) is not generating uketd_dc OAI-PMH data that matches the uketd_dc specification (http://cclib-2.dmz.cranfield.ac.uk/ethostoolkit/tiki-index.php?page=The%20EThOS%20UKETD_DC%20application%20profile). Specifically: - the output is not restricted to only Publications of type "Thesis... This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee)
Re: [Dspace-devel] A few early REST API comments
I want to look over this posting more carefully, but I did want to get one thought out quickly. Please, let's not overload Handles even more. There are sites, I've heard, that would like to do away with Handles and use something else for durable universally-unique external identifiers. That's hard to do if we wire Handles into everything. What we want, it seems to me, is an additional durable identifier which requires only local uniqueness and has *no meaning* in isolation. The last property excludes Handles and DB IDs alike. What this means is that we need, probably, just a simple serial number facility, which is used to name every object created. These names are not used internally by DSpace (as DB IDs are); they exist solely for users to identify "that object you mentioned before". This way, those names can be permanent (unlike DB IDs), don't tie us to specific external services (like Handles), and can't tie us down to specific internal organization (like either). -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] A few early REST API comments
Hi Mark:
Thanks for the thoughtful response.
The point about handles was not intended to enshrine that particular ID system;
I meant it as illustrative ("persistent IDs, _such as_ handles"). I certainly
agree that
a REST API should not enforce any particular scheme, and we have made some
headway in abstracting identification services in the platform.
If your persistent ID of choice is something else, the the REST API should
expose it.
Whether the use of Handles is appropriate (if that's your ID system) in this
context,
or whether DSpace needs a new persistent ID system with the characteristics you
outline is more debatable I think,
and raises many thorny questions (if only locally unique, how can content
stewardship be transferred without collisions?, etc)
that are quite important, but I think to some degree orthogonal to the REST API
design features I was trying to point out.
But point definitely taken, and I'll try to use more neutral descriptions (PID
maybe?), which I agree is the issue at hand here.
Richard R.
On Nov 8, 2013, at 9:51 AM, Mark H. Wood wrote:
> I want to look over this posting more carefully, but I did want to get
> one thought out quickly. Please, let's not overload Handles even
> more. There are sites, I've heard, that would like to do away with
> Handles and use something else for durable universally-unique external
> identifiers. That's hard to do if we wire Handles into everything.
>
> What we want, it seems to me, is an additional durable identifier
> which requires only local uniqueness and has *no meaning* in
> isolation. The last property excludes Handles and DB IDs alike. What
> this means is that we need, probably, just a simple serial number
> facility, which is used to name every object created. These names are
> not used internally by DSpace (as DB IDs are); they exist solely for
> users to identify "that object you mentioned before".
>
> This way, those names can be permanent (unlike DB IDs), don't tie us
> to specific external services (like Handles), and can't tie us down to
> specific internal organization (like either).
>
> --
> Mark H. Wood, Lead System Programmer mw...@iupui.edu
> Machines should not be friendly. Machines should be obedient.
>
> --
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] A few early REST API comments
I don't think I'm able to see too far into the future on this (or any) API.
I see it as more a means to an end. This new machine interface will be a
pleasant way to get data out of your repository, repurposed into other
systems. Clients of the API should expect a stable interface for a period
of time, that they can build applications/uses against. I'm not envisioning
long-term-persistent API, but if you know what your looking for, it will
give you a way to use it.
A quick-win (not quick enough for 4.0) would be to introduce some type of
UUID on objects. They should be some type of globally-unique ID, I don't
see this being used for citation purposes, but if a collection, and its
content were moved from one repository to another, if it could retain this
UUID, and you can keep referencing the same identifier. Overcoming the DB
incremented entity ID, and not binding yourself to an overloaded handle.
Then regarding the entity vs entity-lists. I think the route that I'm
currently on _could_ be a bit bloated, where you request a specific
community, and you can also bring along its child-collections, and
child-communities. It might be cleaner / more-restful to move that
expansion, or just provide some syntax sugar to ask for a more restful
expansion, i.e. /communities/123/collections and
/communities/123/communities and /communities/123/items. Such that the
"communities/" returns a entity-list, i.e. community list,
"communities/123" returns a singular entity i.e. community, and so on down
the line.
I haven't touched the REST API for the past week to let some of the dust
settle, but I am in favor of wrapping responses, and including the request
context, so that regarding pagination, you have enough state/hints to know
how far you can paginate to. We do have limit and offset present currently,
so you can form your own pages.
Peter Dietz
On Fri, Nov 8, 2013 at 10:49 AM, Richard Rodgers wrote:
> Hi Mark:
>
> Thanks for the thoughtful response.
> The point about handles was not intended to enshrine that particular ID
> system;
> I meant it as illustrative ("persistent IDs, _such as_ handles"). I
> certainly agree that
> a REST API should not enforce any particular scheme, and we have made some
> headway in abstracting identification services in the platform.
> If your persistent ID of choice is something else, the the REST API should
> expose it.
>
> Whether the use of Handles is appropriate (if that's your ID system) in
> this context,
> or whether DSpace needs a new persistent ID system with the
> characteristics you outline is more debatable I think,
> and raises many thorny questions (if only locally unique, how can content
> stewardship be transferred without collisions?, etc)
> that are quite important, but I think to some degree orthogonal to the
> REST API design features I was trying to point out.
>
> But point definitely taken, and I'll try to use more neutral descriptions
> (PID maybe?), which I agree is the issue at hand here.
>
> Richard R.
>
>
> On Nov 8, 2013, at 9:51 AM, Mark H. Wood wrote:
>
> > I want to look over this posting more carefully, but I did want to get
> > one thought out quickly. Please, let's not overload Handles even
> > more. There are sites, I've heard, that would like to do away with
> > Handles and use something else for durable universally-unique external
> > identifiers. That's hard to do if we wire Handles into everything.
> >
> > What we want, it seems to me, is an additional durable identifier
> > which requires only local uniqueness and has *no meaning* in
> > isolation. The last property excludes Handles and DB IDs alike. What
> > this means is that we need, probably, just a simple serial number
> > facility, which is used to name every object created. These names are
> > not used internally by DSpace (as DB IDs are); they exist solely for
> > users to identify "that object you mentioned before".
> >
> > This way, those names can be permanent (unlike DB IDs), don't tie us
> > to specific external services (like Handles), and can't tie us down to
> > specific internal organization (like either).
> >
> > --
> > Mark H. Wood, Lead System Programmer mw...@iupui.edu
> > Machines should not be friendly. Machines should be obedient.
> >
> >
> --
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models.
> Explore
> > techniques for threading, error checking, porting, and tuning. Get the
> most
> > from the latest Intel processors and coprocessors. See abstracts and
> register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___
> > Dspace-devel mailing list
> > Dspace-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
>
> --
> Nove
Re: [Dspace-devel] A few early REST API comments
Thinking about this a bit more, I've come round to the position that I don't see why database record IDs are a problem in this context. All we need to do is to inform people that we explicitly deny long-term meaning to these identifiers; they should be assumed to have session scope. If you store one and expect it to refer to the same object after your program exits, you are breaking the rules and may get the confusion that you deserve. If you happen to notice that they seem to correspond to database record IDs, that is not a guarantee that they will continue to do so. If you happen to notice that they seem to persist for months or years, that is not a guarantee that they won't be different tomorrow. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1751) Request a copy of the document page has 'Mensaje:' (should be message?)
Title: Message Title Mark H. Wood assigned an issue to Mark H. Wood DSpace / DS-1751 Request a copy of the document page has 'Mensaje:' (should be message?) Change By: Mark H. Wood Assignee: Mark H. Wood Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1751) Request a copy of the document page has 'Mensaje:' (should be message?)
Title: Message Title Mark H. Wood commented on an issue Re: Request a copy of the document page has 'Mensaje:' (should be message?) Now lightly tested. A few small punctuation and word-order adjustments have been added to correct *my* errors. Add Comment DSpace / DS-1751 Request a copy of the document page has 'Mensaje:' (should be message?) Submit an item then change its authorisations so that it isn't available for anonymous read. Log out, then view the item. *Reporter*: Sean *E-mail*: [mailto:sean.ca...@gmail.com] This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/
[Dspace-devel] [DuraSpace JIRA] (DS-1751) Request a copy of the document page has 'Mensaje:' (should be message?)
Title: Message Title Mark H. Wood updated an issue DSpace / DS-1751 Request a copy of the document page has 'Mensaje:' (should be message?) Change By: Mark H. Wood Documentation Status: Not Required Status: Volunteer Needed Accepted Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1751) Request a copy of the document page has 'Mensaje:' (should be message?)
Title: Message Title Mark H. Wood updated an issue DSpace / DS-1751 Request a copy of the document page has 'Mensaje:' (should be message?) Change By: Mark H. Wood Status: Accepted Code Review Needed Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1751) Request a copy of the document page has 'Mensaje:' (should be message?)
Title: Message Title Mark H. Wood updated an issue DSpace / DS-1751 Request a copy of the document page has 'Mensaje:' (should be message?) Change By: Mark H. Wood Labels: collector-60e7afac has-pull-request Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
