Do you have a suggestion for a new property or function? Please provide a use case and specifics.

[Joan Starr]

[Joan Starr]

I have a client who would like us to clarify that the use of initials (with or without periods) is permitted for Creator names. I have done a review of names in the MDS and this is certainly the common usage so far. I suppose this would also apply to names listed in Contributor.

[Frank Toussaint]

Dear DataCiterians,

at the World Data Centre for Climate (WDCC) we recently came across a problem which might raise to a bigger one: For the first time a scientist refused to have his data referenced by a DataCite DOI. The problem is the different meaning of "Author" in metadata (MD) sets of inhomogeneous DATA GROUPS. For MD sets of single publications there is no problem.

The classical concept of "author" refers to the person who has (or should have) intellectual property rights regarding the data. Unlike this, a coordinator, editor or data collector has production related merits rather than content related, although he/she mostly has the responsibility on the data package as a whole. This is why this person usually is marked by "(Ed.)" behind the name (see, e.g., the reference recommendation on page ii of the new IPCC report at http://www.climatechange2013.org/images/report/WG1AR5_Frontmatter_FINAL.pdf ).

The problem is, that things went differently in the databases' (DBs) world - maybe triggered by schemas like Dublin Core. The responsible person for a collection often is called "author", despite a lack of scientific intellectual contributions, as e.g., in
     doi:10.1007/978-3-642-37244-5
where actually only two of the three "authors" made a contribution to the book's texts.

Here is, where our practical problem arose: The coordinator of a collection of model data from about 30 institutes and some hundreds of real authors refused to be called "author", although he was responsible for this range of data - it was not his merit - he just felt coordinator, not author.

At the American Geophysical Union's fall meeting last December in San Francisco I talked to various scientists of our climate research community. There was complete agreement that only the primary producers of data should be called "authors", well distinguished from editors, collectors and coordinators. I was urged to commit myself to changing this as I represented one of the big data centres.

So what is needed is IMHO a neutral concept for the main responsible person, as we have in DataCite (creator) and a role for it which refers to "author", "collector", "coordinator", and so on. The creator then is to decide on what should be selected.

In the present schema (DataCite 3.0), there are two drawbacks:
A coordinator only can be stored as contributor - whether or not he/she is the main responsible person.
And even worse:
DataCite seems to export MD records in the DublinCore schema - with the "creator" transformed into "author".

So I propose that we:
1) give roles to the Creator, as only by roles in the MD we can cope with the different roles in real live. Other community driven concepts than the above are welcome.
2) try to have the "author" changed to "creator" or any other neutral concept.

I also will discuss this at the World Data System and Research Data Alliance working groups.

Best regards...      frank

[Frank Toussaint]

Hi - I think we can agree on this, as sometimes data are given to data centres without further information. However, we should deprecate this as it makes unique identification of an author more difficult.
Best... frank

[Joan Starr]

Hi Frank,

Thank you for your thoughtful suggestion. We will carefully consider your proposal to add roles to the Creator property at our next meeting in April. Regarding your preference of the term "Creator" over "Author," we clearly favor this as well, and while we have no control over how our metadata is mapped to other standards, we can participate in outreach efforts to promote this term. We will discuss this with our DataCite colleagues in a broader context than the Metadata Working Group.

Best regards,
Joan Starr
Chair, DataCite Metadata Working Group

[Joan Starr]

Hi Frank,

The Metadata Working Group met today. We reviewed your request to add roles to the Creator property. As it happens, this is something that we have considered before in the fall of 2013. As before, today we decided that our existing delineation of the "Creator" and "Contributor" properties is adequate. We want to avoid adding unnecessary complexity to the schema, and we think this would happen if we were to add roles to Creator when they are available in Contributor.

Thank you again for taking the time to communicate with us.

Best regards,
Joan Starr
Chair, DataCite Metadata Working Group

[Chris Taylor]

Dear DataCite,

I'm struggling to identify datasets linked to published papers (to use as a mark of likely quality for filtering).

Different contributors to DataCite are using different approaches* and anyway can do little more than imply that status; even checking DOIs to see if one hits a published paper doesn't work reliably because not all papers have DOIs (e.g., conference proceedings, fairly frquently).

What would be ideal is a boolean (published/not) up top, supplemented by some kind of formally specified use of relatedIdentifier. Any chance?  :)

Best wishes, Chris Taylor.

-------------------------------------

* Examples:

'Dryad style':

<relatedIdentifier relationType="IsReferencedBy" relatedIdentifierType="DOI">10.1016/J.YMPEV.2011.06.012</relatedIdentifier>

'3TU style':

<relatedIdentifier relationType="IsSupplementTo" relatedIdentifierType="DOI">10.1016/j.marmicro.2009.03.003</relatedIdentifier>

And something that looks a bit like a paper, but isn't (it's a master's thesis):

<relatedIdentifier relatedIdentifierType="URL" relationType="References">http://resolver.tudelft.nl/uuid:d60a9711-aefc-44fa-b91e-1ab47930f2ec</relatedIdentifier>

And one that doesn't look published, but is (in conference proceedings):

http://data.datacite.org/10.5061/DRYAD.8C1P6

[Chris Taylor]

Actually probably better to have a series of values rather than a boolean so we could specify the manner of publication (0/null = none; 1 = peer-reviewed journal; 2 = conference proceedings; 3 = thesis for a higher degree; other values for white papers, book chapters, monographs, self-published, pre-print, etc.).

[Joan Starr]

HI Chris,

The Working Group will certainly discuss this issue. An additional wrinkle that occurs to me is the following: the overwhelming majority of the metadata in the DataCite Metadata Store reflects the state of the relations at the time of registration for the DOI. I am certain that virtually everyone who seeks a DOI for their data object is hoping others will cite the object in their papers, and yet this information is (so far) relatively difficult to capture. If you are hoping to use any flag we might add as a quality filter, it would be a shame if you missed the data objects that get their publication relationship(s) added after the DOI was assigned, but the DOI owner was not aware of it, and so did not, could not, or would not update the metadata. The "long tail" for data, so to speak.

Something too consider?

Joan Starr
Chair, DataCite Metadata Working Group

On Thursday, August 8, 2013 10:40:21 AM UTC-7, Joan Starr wrote:

[Chris Taylor]

Hi,

Absolutely! Capturing (indications of) re-use would be extremely desirable - the economics of data sharing depend on such systems coming into being, to ensure credit can be claimed and so on. Seems like something relevant to the ORCID/ODIN activity at that point?

The existing structures seem amenable to this, perhaps some agreed terms would suffice? Also I suppose an agreed way to append new references, and with a way to indicate which is the 'index' paper (the one the owner wants you to cite...).

This is great stuff, thanks :)

Best wishes, Chris.

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[John Howard]

I’d like to draw to your attention a concern about the OpenAIREplus usage of the DataCite 3.0 schema. It in effect utilises the Contributor data element for reporting of funder and funding information that is otherwise used primarily for name identifiers; the OpenAIREplus usage is described at https://guidelines.openaire.eu/wiki/Data_Guidelines:_Metadata_Property_Contributor. (Note that the guideline does not apply to Creator.)

The DataCite definition of the nameIdentifier data element reads "Uniquely identifies an individual or legal entity, according to various schemes", which is distinctly different from the OpenAIREplus usage. For data providers contributing to OpenAIREplus, the constraint on single occurrences of the data element requires a choice between reporting a funder name with a linkage to a record of the funder name from a standard vocabulary, and reporting funding information that OpenAIREplus requires.

I would not be an advocate for removing the existing constraints on the nameIdentifier element. I would, however, propose that the OpenAIREplus requirements for metadata on funder awards be considered by the DataCite metadata group to provide an alternative solution, so that DataCite's prescribed usage must not be foregone in order to comply with OpenAIREplus's local needs. I understand that this might be seen as an OpenAIREplus implementation matter, however, since DataCite metadata is used by other organisations as well, it would be useful for data consumers for usage of the schema to be made around a common set of shared guidelines.

Best regards,

John

[Lars Holm Nielsen]

Dear John,

Thanks for bringing this up. I'm co-editor of the OpenAIRE Guidelines for Data Archives as well as a new member of the DataCite Wokring Group. With "Uniquely identifies an individual or legal entity, according to various schemes" I personally understand that it is the identifier itself that has to uniquely identify an entity, not that the occurrence of an entity has to be unique. Thus, as I understand the text, it is allowed to include both e.g. a FundRef identifier and info:eu-repo identifier to the same grant. My personal view (I haven't consulted this with the WG), is that the DataCite schema in this respect is fine, but that perhaps the documentation needs to clarified.

It is naturally not ideal that you include the same grant twice, but I see that more as an issue with the OpenAIRE guidelines which only supports info:eu-repo vocabulary as the only grant identification scheme (due to the underlying infrastructure). I however do believe that in the longer run, OpenAIRE will be supporting other grant identification schemes.

Best regards,

Lars Holm Nielsen

[John Howard]

Dear Lars,

Thanks for the quick reply! Do I understand correctly that you are suggesting that one potentially list the same funder as a Contributor twice--once in order to reference it with an identifier (as from FundRef) and another time to cite the grant using the info:eu-repo approach?

I would understand that if one identifies a funder as a Contributor, then the nameIdentifier should provide a reference that also identifies the funder. The OpenAIRE usage does not use the nameIdentifier to identify the funder, but instead associates a specific grant award with the funder. I'm still seeing these usages as quite different.

I'm happy to follow the practice I think you're recommending but wonder if there may not be a more elegant approach possible? What if, for example, Thomson Reuters also issued a guideline for reporting grant information using a different approach to use of the DataCite schema ... or might there agreement with TR around the OpenAIRE approach?

thanks,

John

[Joan Starr]

Hello to you both,

Let's hold off on this discussion for the time being. As noted above, the Metadata Working Group is now focused on preparing our next release. Moreover, this is a topic that will require discussion on our part. There are some issues here we'll want to examine.

Thank you,

Joan Starr
Chair, DataCite Metadata Working Group Chair

[Elise Dunham]

Hi,

In the Subject property, it's great that there is support for identifying the subject scheme used, but I would also like to have an attribute for capturing the id for a specific term. So for this case:

<subjects>

<subject xml:lang="en-us" schemeURI="http://id.loc.gov/authorities/subjects.html" subjectScheme="LCSH">Cats</subject>

</subjects>

I'd like to do something like:

<subjects>

<subject xml:lang="en-us" schemeURI="http://id.loc.gov/authorities/subjects.html" subjectScheme="LCSH" termURI="http://lccn.loc.gov/sh85021262">Cats</subject>

</subjects>

An approach like this seems to me like it would be much more interoperable/linked data-ready. 

I'd appreciate any thoughts/feedback about this and am happy to provide more information if necessary.

All best,

Elise Dunham

Elise Dunham

Data Curation Specialist, Research Data Service (RDS)

University of Illinois at Urbana-Champaign

On Thursday, August 8, 2013 at 12:40:21 PM UTC-5, Joan Starr wrote:

[Joan Starr]

Hi Elise,

Thank you very much for the suggestion. I will take this to the Working Group for discussion.
Best regards,

Joan Starr
Chair, DataCite Metadata Working Group

[JanA]

Posted on behalf of the STFC and added to the 'Changes under consideration' for version 4.0. Posted here for information and comment.

At a BL Client meeting on 6 July 2015 the UK Science and Technology Facilities Council outlined a project on Software citation. They propose using the DataCite metadata schema and are liaising with the Force 11 software citation group (Lars Holm Nielsen is helpfully on this group too). They have some specific suggestions for additions to the DataCite schema in this context:

 

1. <Resource Type>: some clarification between ‘software’, ‘workflow’, ‘interactive resource’ and ‘service’ when considering software and packaged software which then runs once unpacked.

2. <Resource Type>: Would it be useful to have a list for further defining ‘software’ with more granularity.

3. Look at relation type to see if all software relationships are covered and to ensure consistent use of terms e.g. our ‘Compiles’ / ‘isCompiledBy’ means something different to a software developer!

4. <Description>: suggest new subtype of ‘TechnicalInfo’ to encourage people to put more details that people who want to use the software might need to use to decide whether it is worth investigating.

5. <Description>:  would ‘Summary ‘possibly be better than ‘Abstract’ as a label?

[Matthew McKinley]

Suggestion to implement support of Polygon geospatial coverage in addition to geoLocationPoint and geoLocationBox:

I see the polygon shape in geospatial MD as a sort of middle-ground between the bounding box (which represents an area in a very abstract & not extremely accurate way) and an area represented as a geographic area via a shapefile (https://en.wikipedia.org/wiki/Shapefile). A shapefile can represent a geographic area in a very detailed & accurate way but has the disadvantage of being a separate file, understandable only via specialized software and unable to manifest as linked data without some sort of intermediary. While a polygon won’t ever offer the full range of geographic expression available via an accompanying shapefile, it could provide much more accuracy and detail than a bounding box while still being discrete enough to express via XML or JSON etc., meaning it could be interpreted and reused as linked data.

 

Here's a visual example via Google Maps: https://www.google.com/maps/d/edit?mid=zpwWvJCt-wz8.kubaqOtUg1VE. A more nuts and bolts example/inspiration of how DataCite might implement would be geoJSON, which defines a Polygon Geometry Object (http://geojson.org/geojson-spec.html#polygon) and provides a code example (http://geojson.org/geojson-spec.html#id4). The basic way they implement is an ordered series of coordinate pairs, with the requirement that first and last pair are identical in order to “close” the polygon.

 

It’s worth noting that geoJSON has also been discussed by the geoBlacklight community (EX: https://github.com/geoblacklight/geoblacklight/issues/53), though I’m not sure if this extends to implementing specific geoJSON metadata structure.

[Joan Starr]

Hi Matthew,

Thank you for the suggestion. The Metadata Working Group will discuss it. We meet monthly, and we have a rather full agenda, so there may be a bit of a delay before we are able to get back to you with a response. However, we will get back to you.
Thanks again,
Joan Starr
Co-chair, DataCite Metadata Working Group

[Joan Starr]

Hi John,

Thanks again for bringing this to our attention. Today the working group approved the addition of a new property for the description of funding information. It will support supplying name, identifier, identifierType, award number and award URI. Implementation details are still to be worked out, but I wanted you to know that this change will be included in the next release.
Best,
Joan Starr
co-chair, Metadata Working Group

[marko6...@gmail.com]

Dear all, at the Treaty we are about to start minting DOIs associated to Plant Genetic Resources (PGR, think of seed bags in genebanks). One of the main features of our system will be keeping track of the relations among our DOIs. For instance, when a PGR sample is transferred from one institution to another, a new DOI is minted for the sample when it is incorporated into the recipient's collection. The DOI on the provider's side and the new DOI on the recipient's side are in a relation (we call the corresponding operator "acquiredFrom").

Likewise, when a breeder crosses two or more samples to obtain a new variety or preforms some genetic modifications, the new material is given a new DOI related to the parent or original material(s) through our operator "createdFrom". Finally, if purification or selection procedures are performed on an original material, the new material's DOI is related to the original DOI through the "derivedFrom" operator. Sofar, these are the operators we have identified, but more could be added in the future, as we extend our system to more PGR procedures.

The question we are submitting to the MDWG, then, is whether it would be possible to add more specific operators to the controlled vocabulary of 12.2 relationType. By reading the current list, we could map:

derivedFrom -> isDerivedFrom

createdFrom -> isVariantFormOf

acquiredFrom -> isNewVersionOf

but the meaning of the operators could be different from other fields of application. What is the position of the MDWG about field-specific operators? Should we use the above mapping (or another one) or could you consider adding our own operators to the list?

On the same topic, although probably not relevant to the MDWG is the fact that "popular" PGR materials may be transferred hundreds or thousands of times, which will result in hundreds or thousands of relatedIdentifiers associated to their DOIs? Is there any problem with so many related DOIs?

Thank you for your consideration!

Marco

[Martin Fenner]

Am 08.07.2016 um 18:01 schrieb marko6...@gmail.com:

On the same topic, although probably not relevant to the MDWG is the fact that "popular" PGR materials may be transferred hundreds or thousands of times, which will result in hundreds or thousands of relatedIdentifiers associated to their DOIs? Is there any problem with so many related DOIs?

Marco,

I will try to answer this part of your question. In general we recommend to issue a DOI for a specific resource, independent of the location. It is common for digital resources to be hosted in more than one location, but it is still the same resource. If this is similar to your use case of transferring a PGR resource from one institution to another, then they should use the same DOI. If there is a real difference between the two (so more than the location), then a new DOI is appropriate, and "New version of" seems a good relationType. If you need to mint hundreds of thousands of DOIs, than so be it. You see something similar in what GBIF is doing with biodiversity information, and you might talk to them to learn more. For biodiversity information location is of course highly relevant, and therefore the need to issue lots of DOIs. They have the highest numbers of relatedIdentifiers per DOI, for example http://search.datacite.org/works/10.15468/DIPJCR with more than 15k relatedIdentifiers.  

Best,

Martin

[Marco Marsella]

Dear Martin, as usual your replies are very helpful. Yes, for Plant genetic Resources, as soon as the material is moved from one collection to another, it indeed becomes a “different” thing. In some cases, it is possible that the material becomes genetically different due to contamination or drift. In all cases, the legal rights and obligations under which the material is placed when in the recipient’s collection make it indeed something else.

Cheers

M

[Joan Starr]

Hi Marco,
I'll try to respond to the other part of your question, "What is the position of the MDWG about field-specific operators? Should we use the above mapping (or another one) or could you consider adding our own operators to the list?" In general, the WG has tried to avoid adding data centre specific solutions to the metadata schema. The mechanism that we adopted to allow users to add their own metadata is the HasMetadata relationType. With this, you can refer to an external file with any kind of metadata you wish to add to the file. Please review the documentation for this element and see if it will meet your needs as an alternative to using the mappings you have described.
Thank you,
Joan Starr
Co-Chair, Metadata Working Group

On Thursday, August 8, 2013 at 10:40:21 AM UTC-7, Joan Starr wrote:

[David Valentine]

Looking at V4 proposal:

Should locations be able to have some reference to enable linked data referencing?

[Barton, Amy J]

Hi David,

 

We are wrapping up work on the first versions of the DC2AP and DC2RDF. Thank you for the question. We think linked data referencing for locations is a good idea.

 

All the best!

Amy

 

Amy J. Barton (née Hatfield), MLS

Assistant Professor of Library Science, Metadata Specialist

Purdue University Libraries, Research Data

(765) 494-6333

hat...@purdue.edu

STEW, 348

orcid.org/0000-0002-2184-3723

--
You received this message because you are subscribed to the Google Groups "DataCite Metadata" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datacite-metad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rachael Kotarski]

Hi,

We have had a query on whether an identifier could be used for the Affiliation sub-property of Creator (or Contributor).

As Affiliation is currently free text, is it appropriate to put an organisational identifier here, and if not, should OrgID be an attribute of affiliation?

Thanks, Rachael.

On Thursday, 8 August 2013 18:40:21 UTC+1, Joan Starr wrote:

[Andrea Perego]

+1 to supporting identifiers for affiliations. For backward
compatibility, I guess the preferable option is to use an attribute,
or a separate element.

Andrea

[Martin Fenner]

Rachael and Andrea,

I agree that an identifier for affiliations would be very valuable, and consistent with what we do in other places of the schema. I recommend not to put any identifiers in the free text field that is currently available, it would be hard to index and display and might rather confuse everyone.

Best,

Martin

--

Martin Fenner
DataCite Technical Director
http://orcid.org/0000-0003-1419-2405

[Andrea Perego]

Hi, Martin.

On Thu, Oct 12, 2017 at 10:51 AM, Martin Fenner
<martin...@datacite.org> wrote:
> Rachael and Andrea,
>
> I agree that an identifier for affiliations would be very valuable, and
> consistent with what we do in other places of the schema. I recommend not to
> put any identifiers in the free text field that is currently available, it
> would be hard to index and display and might rather confuse everyone.

I totally concur.

Andrea

[Rachael Kotarski]

Thanks both!

[sophi...@nrc-cnrc.gc.ca]

Hi,

The language attribute is available for a few elements (i.e. title, abstract). Could it be made available for more elements (i.e. creator, publisher, contributor)?

The National Research Council of Canada does create some content in French and English. For French content, we prefer to provide French metadata values  but some corporate names are not always available in French. Adding language values would provide a clearer picture for harvesters of this metadata.

Also language attribute can be leveraged when displaying the metadata on web pages (useful for screen readers).

Example #1:

French publication and French name of publisher exists:

<language>fr</language>

<publisher>Conseil national de recherches Canada</publisher>

Ideal would be

<language>fr</language>

<publisher xml:lang="fr">Conseil national de recherches Canada</publisher>

Example # 2 

Publication  written by an English contracting company and published in English and French by NRC

<language>fr</language>

<publisher>Conseil national de recherches Canada</publisher>

<creatorName>RenewableTechs Inc.<creator>

Ideal would be

<language>fr</language>

<publisher xml:lang="fr">Conseil national de recherches Canada</publisher>

<creatorName xml:lang="en">RenewableTechs Inc.<creator>

Thank you for considering this suggestion.

Sophie

On Thursday, August 8, 2013 at 1:40:21 PM UTC-4, Joan Starr wrote:

[Barton, Amy J]

​Hi Sophie,

Thank you for the suggestion and examples.

The DataCite Metadata Working group is now working on the next version for our metadata. We will take your suggestion to the group for discussion.

All the best!

Amy

Co-Chair

DataCite Metadata Working Group

Amy J. Barton, MLS

Assistant Professor of Library Science, Metadata Specialist

Purdue University Libraries, Research Data

(765) 494-6333​

hat...@purdue.edu

---

From: datacite...@googlegroups.com <datacite...@googlegroups.com> on behalf of sophi...@nrc-cnrc.gc.ca <sophi...@nrc-cnrc.gc.ca>
Sent: Friday, December 15, 2017 10:33 AM

To: DataCite Metadata
Subject: Re: Do you have a suggestion for a new property or function? Please provide a use case and specifics.