Reference Lookup Service

[michael]

We want to introduce a service for retrieving References and use it in the Texture user interface. The idea is that we send a search string (e.g. a DOI or a publication name) to services such as Crossref/DataCite and retrieve a complete element-citation record.

The desired interface looks like this:

GET http://example.com/reflookup?q=Context-specific%20grasp%20movement%20representation

Returns:

<result>
  <element-citation publication-type="journal">
    <person-group person-group-type="author">
      <name>
        <surname>Baumann</surname>
        <given-names>MA</given-names>
      </name>
      <name>
        <surname>Fluet</surname>
        <given-names>MC</given-names>
      </name>
      <name>
        <surname>Scherberger</surname>
        <given-names>H</given-names>
      </name>
    </person-group>
    <year iso-8601-date="2009">2009</year>
    <article-title>Context-specific grasp movement representation in the macaque anterior intraparietal area</article-title>
    <source>Journal of Neuroscience</source>
    <volume>29</volume>
    <fpage>6436</fpage>
    <lpage>6448</lpage>
    <pub-id pub-id-type="doi">10.1523/JNEUROSCI.5479-08.2009</pub-id>
  </element-citation>
</result>

As a result we get a an XML document, consisting of 0..n element-citation records. The records must conform to the JATS4R spec for element-citation, which we are defining here: #238

Questions

• Who can implement that service? Texture only defines the interface, but implementation/and maintenance of the lookup service is up to platform providers
• What to do in an offline scenario? We propose to allow service integration such as ref lookup as a drop-in (when there is an active internet connection). If the internet connection drops you could still continue editing without interruption
• Should users be able to edit automatically retrieved records? (we would suggest to lock them for editing until the users deliberately unlocks them (which means the data is no longer guarateed to be linked to the online record and could contain user errors)

[mfenner]

The DataCite content negotiation service works with Crossref and DataCite DOIs and uses https://github.com/datacite/bolognese to format metadata. Should be straightforward to support JATS XML output.

[fabiobatalha]

@michael

Including SciELO databases: http://articlemeta.scielo.org/api/v1/article/?code=10.1590/1516-4446-2016-1976&format=xmlrsps

[mfenner]

Something that is missing from DataCite content negotation that now returns JATS element-citation is the ability to query - the system works using a DOI. Can you build into texture to do two API calls: a) query Crossref API to get DOI, b) use content negotation to get metadata in JATS XML?

[michael]

@mfenner we could, but it would lead to many separate calls which we need to synchronize. We could do a proxy service that does that and maps it to a sequence of element-citations for the Texture client to consume. However better this would be managed somewhere upstream? :)

In my email today I wrote an HTML string would be good for rendering the list of matches, but now that I thought more about it, I think JATS element-citation records would work best, as we can implement consistent rendering in Texture.

Think about it.. we don't need to rush, and the option you suggested is there too.

[Melissa37]

What to do in an offline scenario? We propose to allow service integration such as ref lookup as a drop-in (when there is an active internet connection). If the internet connection drops you could still continue editing without interruption
Sounds great!

Who can implement that service? Texture only defines the interface, but implementation/and maintenance of the lookup service is up to platform providers
I would hope that there is open source software out there for this as almost every production vendor in India has set up this functionality into their workflow

Should users be able to edit automatically retrieved records? (we would suggest to lock them for editing until the users deliberately unlocks them (which means the data is no longer guarateed to be linked to the online record and could contain user errors)

The metadata at crossref is not perfect, and also all "face mark up" is removed, so important information like sub scripts and italics are dropped. Many authors feel strongly about this data and so should be able to amend it.
Another thing we've noticed is that journal titles are normalised, so again authors need to be able to edit them - eLife is changed to elife. At eLife we have a bunch of exceptions that our vendor converts from the Crossref/PubMed output.
The key data that should not be changed is the DOI, maybe that should not be editable but the other fields are?

[michael]

Who can implement that service? Texture only defines the interface, but implementation/and maintenance of the lookup service is up to platform providers
I would hope that there is open source software out there for this as almost every production vendor in India has set up this functionality into their workflow

The new DataCite JATS service will do the job for us. A first implementation is already there: force11/force11-sciwg#7 (comment)

Should users be able to edit automatically retrieved records? (we would suggest to lock them for editing until the users deliberately unlocks them (which means the data is no longer guarateed to be linked to the online record and could contain user errors)
The metadata at crossref is not perfect, and also all "face mark up" is removed, so important information like sub scripts and italics are dropped. Many authors feel strongly about this data and so should be able to amend it. Another thing we've noticed is that journal titles are normalised, so again authors need to be able to edit them - eLife is changed to elife. At eLife we have a bunch of exceptions that our vendor converts from the Crossref/PubMed output. The key data that should not be changed is the DOI, maybe that should not be editable but the other fields are?

I understand. So let's keep the fields open for editing.

I think we have two use-cases:

1. Create a new reference from Crossref data (interface only shows up when internet connection is available)

2. Update an existing record (manually created or through MS Word conversion)

This interface can be used to link an entry with a DOI, and we can prompt the user if they want empty fields to be populated with metadata from Crossref. However after linking they'll be able to change all data except for the DOI?

How does that sound?

[fabiobatalha]

@Melissa37 @michael

All suggestions sounds good for us.

Is it possible to include more than one metadata source (eg. SciELO). We can develop the same endpoint that DataCite has to retrieve metadata from a given DOI number.

[axfelix]

Yes, this is good, and I agree about giving some kind of interface cue when a user is deviating from looked-up metadata

[Melissa37]

I agree re more than 1 metadata source - some of our use cases would prefer PubMed and PubMedID look up.

I think we need to get this user tested asap though - search online, I think it would be best to prompt the author to put a DOI or PubMedID in here and not say "search online" as this indicates to the user that you are going to search the internet including every publisher page and pull in the details based on whatever wonky metadata they add here as a string!

[michael]

Entering a DOI explicitly instead of a search could be a good first step, easier to implement also. What do the others think?

[mfenner]

I think that entering a DOI is a good first step, but ideally you want a search interface that queries Crossref, DataCIte and other sources. Reference managers (e.g. Papers) allow queries of multiple sources, even in parallel, not sure whether this goes too far for texture. Crossref and DataCite are discussing a common search for their DOIs, but this is at an early stage. I don't think that authors should be able update metadata associated with a DOi. The main reason is that many publishers take the reference list apart and re-assmenble it, so it would be a wasted effort. Also, I don't see the value of producing multiple versions of metadata for the same thing - at the end of the day the canonical source is the metadata from the publisher of that work, and not what the author has put in. Best, Martin

On Wed, Nov 1, 2017 at 4:14 PM Michael Aufreiter ***@***.***> wrote: Entering a DOI explicitly instead of a search could be a good first step, easier to implement also. What do the others think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#276 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABab5t4FuJGk6vCBggOMwySqXMRE0nZks5syIrbgaJpZM4Pgts_> .

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

[michael]

Hey Martin!

Saving reference data to an external DB would only be available to people of the journal production team, not for authors. Same is true for the proposal here #284.

[pigeonm]

Hi !

At Erudit, we agree with mfenner's comment: ultimately, what we want is the canonical version of a bibliographic reference. What we are looking for is the structure of a citation, not it style (eg, italic).

About the appearance of a citation (eg, the title has been italicized), does Texture integrate different citation style (subject addressed in issue #238 ), because the appearance of a citation could be the result of the style chosen by the user (APA, Chicago, Vancouver, etc.). The support of citation styles in Texture might be discussed in a dedicated issue?

However, we are still concerned about the variable quality of some metadata at Crossref, so it seems to be a good idea to let the door open to the possibility of editing citations if needed. We don’t want it to be Texture that prevents us from editing a reference if we consider that it must be edited. Eg, see the case where Crossref sends back citations where the “sup” markup have been removed: we would want edit the citation to to add the “sup” markup back.

[Melissa37]

Agree with all except that "face mark up" matters to some readers and users and they should be able to add sub/super-script and italics to titles of papers if they want to. I have an inhouse editor who would have a major problem if I did not allow this to happen.
I agree that whether a journal title is in italics or Roman is a style issue that each publisher will do differently and so should not be Texture's job to sort.

[michael]

Closing this as we have an initial implementation and will advance based on new issues.