Hi Jere and all, Correct, I don't believe any development has started on DS-3472, as that ticket is still in a "Needs More Details" status.
https://jira.duraspace.org/browse/DS-3472 Tickets in that state are often waiting for feedback or best practices to be proposed. As developers, we don't always know what the best solution may be for repository managers/harvesters (or for metadata storage in general). So, we occasionally have to set aside tickets for more feedback. Plus, to be honest, all our development work is volunteer based -- so even if we got this feedback *today*, we'd have to look around for someone interested/available in helping build out the proposed solution. My recommendation here would be to try to gather together others who are interested in helping propose a solution, perhaps either on this list, or possibly the DCAT group can be used for finding interested folks: https://wiki.duraspace.org/display/cmtygp/DSpace+Community+Advisory+Team The more clarity we (as developers) can get on what is the "best practice" here, the more likely we can move this forward in the near future. - Tim On Wed, Oct 31, 2018 at 7:59 PM Jere Odell <[email protected]> wrote: > Hi helix84, > > Thanks for linking to Jira DS-3472. Very helpful. Mark Diggory recommended > providing configurable options. As far as I know this hasn’t been a focus > for development yet. Correct? > > I don’t think DS-3472 addresses our worries about how other systems use or > fail to use multiple values stored as identifier.uri ... any thoughts > anyone? > > Jere > > Sent from my iPhone > > > On Oct 31, 2018, at 7:18 PM, helix84 <[email protected]> wrote: > > > > See also the previous discussion of this issue in Jira: > > > > https://jira.duraspace.org/browse/DS-3472 > > > > > > Regards, > > ~~helix84 > > > > Compulsory reading: DSpace Mailing List Etiquette > > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette > > > >> On Wed, Oct 31, 2018 at 10:42 PM Jere Odell <[email protected]> > wrote: > >> > >> I would like to ping Mark Wood's questions on this thread one more time > ... Mark and I use very different language for describing what we want to > do ... as a repository manager I want to: > >> > >> 1. automatically register DOIs (the manually process is tedious) > >> 2. store those DOIs in metadata fields that are meaningful to both > machines and to people (but, yes, machines are probably more important, in > this case) > >> 3. do the above without modifying dspace such that future upgrades are > a pain in the neck. > >> > >> I agree with the few repository managers that responded that DOIs are > best stored in dc.identifier.doi ... and that external DOIs (those that we > do not register) should be stored in another field (version.isrelationof, > for example) ... but this is the human readable solution. I assume that > those that responded with this arrangement are registering DOIs manually or > are at the very least not using dspace to make the registration. > >> > >> It makes sense to me (sort of) as Mark says: "A system which creates > identifiers for its own purposes must know which identifiers it controls." > ... which means for now, dspace should store these in dc.identifier.uri. > But ... > >> > >> Can anyone confirm that we are not creating downstream headaches for > systems that seek to make sense of the multiple values stored in > dc.identifier.uri? Or ... as Mark says: > >> > >> "What is the appropriate, standardized or generally accepted mapping of > "DOI for this version of a resource" for interchange among heterogeneous > systems?" > >> > >> AND > >> > >> "[N]on-brittle external systems will [parse the different types of > identifiers] anyway to protect themselves from unknown practices at sites > that they harvest. Do we know of any systems which do not?" > >> > >> Any thoughts on these questions? > >> > >> Jere Odell > >> IUPUI > >> > >> > >> > >> > >> > >>> On Thursday, October 11, 2018 at 12:36:08 PM UTC-4, Mark Wood wrote: > >>> > >>>> On Thursday, October 11, 2018 at 11:59:56 AM UTC-4, Jere Odell wrote: > >>>> > >>>> I think there's mismatch between how librarians think metadata should > be applied and how DSpace can auto-register (DataCite) DOIs. If Mark and > Claudia are correct, DSpace generates DOIs in dc.identifier.uri and > [cannot/is not currently able to] register DOIs from other Dublin Core > fields ... such as dc.identifier.doi. > >>>> > >>>> If I understand correctly, DSpace was designed to issue one > persistent identifier ... the handle. DOIs were a more recent request and, > for now, if we want to auto-generate DOIs we have to store them in > dc.identifier.uri. Is that correct? > >>>> > >>>> If so, that puts those of us that want to assign DOIs to our DSpace > records in a difficult spot ... we must choose between a) manual methods of > registering the DOI or b) rely on a less-than-optimal metadata practice. > >>>> > >>>> Am I missing something? > >>>> > >>> > >>> > >>> Perhaps it is I who is missing something. How, specifically, is this > less-than-optimal practice? Some points to consider: > >>> > >>> o There actually is no such field as identifier.uri in Qualified > Dublin Core. So what would an aggregator do with it? It has no meaning > outside of DSpace. It should be mapped to something standardized, when > exposed to harvesters. Screen-scraping harvesters should know they are on > shaky ground and carefully examine the values that they find. > >>> > >>> o Resolvable URLs for DOIs and for general Handles use distinct > authorities (hdl.handle.net vs. dx.doi.org). They are easily > distinguished by humans and by machines. > >>> > >>> o If a raw Handle has the prefix "10." then it is a DOI, otherwise it > is not. > >>> > >>> o How a repository stores a metadata value, and how it presents it, > are separate questions. What is the appropriate, standardized or generally > accepted mapping of "DOI for this version of a resource" for interchange > among heterogeneous systems? > >>> > >>> o A system which creates identifiers for its own purposes must know > which identifiers it controls. Others must know which identifiers they do > not control. I presume that this is why the DOI identifier providers use > one field and the stock submission form uses another. > >>> > >>> I would have preferred that different types of identifiers were stored > separately, so we don't have to parse them to know what they are. But that > isn't difficult, and non-brittle external systems will do that anyway to > protect themselves from unknown practices at sites that they harvest. Do > we know of any systems which do not? > >> > >> -- > >> 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 Community" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >> To post to this group, send email to [email protected]. > >> Visit this group at https://groups.google.com/group/dspace-community. > >> For more options, visit https://groups.google.com/d/optout. > > -- > 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 Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-community. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- 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 Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-community. For more options, visit https://groups.google.com/d/optout.
