Thanks for the thoughtful response, Mark. I think a pretty good list of recommended changes would start with those in the XHTML crosswalk[0]. The author(s) of this crosswalk clearly knew that dc.language.iso and others were not real Dublin Core fields. From looking at the various Dublin Core recommendations (latest 2012, seven years ago!) it seems that should be preferring dcterms.* where possible[1]. I don't want to get into a debate about which color to paint the bike shed (as the joke goes), but some of the fields we are using are wrong and we know it. :)
Regards, [0] https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/crosswalks/xhtml-head-item.properties [1] http://www.dublincore.org/documents/dcmi-terms/ On Fri, Jan 25, 2019 at 4:23 PM Mark H. Wood <[email protected]> wrote: > On Thursday, January 24, 2019 at 9:10:06 AM UTC-5, Alan Orth wrote: >> >> We have started looking at our use of metadata across our repositories >> and I have to say that it is very confusing! First some background as I >> understand it, then the current state of affairs in DSpace 4/5/6, and then >> my question(s). :) >> >> Dublin Core is the original specification of fifteen elements from >> 1995[0]. It was amended in 2000 to add element qualifiers like >> "dc.date.issued" as well as a few new elements[1]. These were both >> superseded in 2008 with the introduction of the Dublin Core Terms (aka >> DCTERMS) specification[2], which essentially combines both of them. >> >> By default DSpace makes heavy use of both simple and qualified Dublin >> Core in its input forms, but also provides crosswalks to translate many of >> these to DCTERMS that are then exposed as metadata in the XMLUI[3][4]. It >> is very easy to change the input forms to use different fields and even >> custom namespaces, though some core fields seem to be dangerous (like >> dc.date.* and dc.contributor.author). >> >> Our repository is consumed ravenously by search engines, but also by >> increasingly many harvesters via REST and OAI APIs. If we want to make sure >> that the metadata these harvesters receive is also standards compliant and >> interoperable, shouldn't we update our input-forms and existing item >> metadata to take some of the crosswalks into mind? For example: to start >> using dc.language or dcterms.language instead of dc.language.iso (I would >> of course update the crosswalks accordingly). Does any of this change in >> DSpace 7? Is there any talk of moving away from a flat schema so that >> authors and institutions could be related, for example? >> >> > > I agree that too little attention is given to interchange, and how careful > we have to be to make M2M communication meaningful without introducing > errors and unwarranted assumptions. > > Since it appears to me that there is no such thing as dc.language.iso, > using dc.language makes sense. There are several DSpace inventions > masquerading as QDC. Some of them should be moved to a different > namespace. No, I haven't yet made a table of my recommended changes. > > There is always talk of moving away from a flat namespace. I think this > may be unnecessary. Authors, for example, are not contained by > institutions; an author writing for or with the sponsorship of an > institution should cause the authorship of the work to be marked with a > relationship to the institution -- that is: an object references another > by unique identifier. It may be convenient to express this externally with > a hierarchial form (e.g. in METS), but that is merely for interchange; > internally we should represent knowledge more flexibly so that we can > produce whatever external representation is required without having to > reverse too many assumptions. An author's employment and membership > history would properly belong in a biographical repository, which (were > such a thing to exist) would have quite a different sort of metadata > structure. Given a sufficiently rich set of simple types, most of what we > know about an author or a work or an institution should be usefully > representable as simple lists. > > We also need to look at enriching our internal representation, but in a > different way. I think it was Mark Diggory who observed that we talk about > "metadata schemas" as if we had them, but what we really have is > namespaces. A schema not only tells you what fields are defined and how > they are named, but what kind of data a field may hold and what values of > that kind are acceptable. A well-written schema will guarantee that the > value stored in a field will make sense. If we declare that > dc.date.accessioned is a date, then even if the UI mistakenly accepts a > value of "Louisiana" as a date, the metadatavalue service would not, > because that can't be understood as a date. We might store the value of > dc.date.accessioned as a string encoding of a date, but then we might store > it as a serialized Calendar, and the schema then tells us how to interpret > the byte array and informs external interfaces of how they might represent > the field's value. Another way of looking at this is that we encode > information in form definitions which might be pushed into the metadata > schemas (if we had them) and fetched by the form interface, allowing us to > simplify the writing of forms. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Alan Orth [email protected] https://picturingjordan.com https://englishbulgaria.net https://mjanja.ch "In heaven all the interesting people are missing." ―Friedrich Nietzsche -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
