CDR Tickets

Fixed on DEV. I deleted CDR778957 and re-imported as CDR779282. Ready for user testing.

At least for two terms that we imported yesterday and today, they appear to be fine without any duplicated information. However, the problem appears to continue for some of the imported documents, especially cases of triplicated Definition texts. The Other Name is duplicated also but that may be because of the differences in the Source Types. Here are two terms with such problems

CDR0000779358
CDR0000779355

Is everything you're describing in this comment for activity on DEV? Or is at least some of it referring to PROD (or some other tier)?

Yes, that was from testing on DEV.

I just looked at CDR779358, and the OtherName blocks are not duplicates of each other.

<OtherName>
  <OtherTermName>Gene Solution</OtherTermName>
  <OtherNameType>Synonym</OtherNameType>
  <SourceInformation>
    <VocabularySource>
      <SourceCode>NCI Thesaurus</SourceCode>
      <SourceTermType>PT</SourceTermType>
      <SourceTermId>C123897</SourceTermId>
    </VocabularySource>
  </SourceInformation>
  <ReviewStatus>Reviewed</ReviewStatus>
</OtherName>
<OtherName>
  <OtherTermName>Gene Solution</OtherTermName>
  <OtherNameType>Synonym</OtherNameType>
  <SourceInformation>
    <VocabularySource>
      <SourceCode>NCI Thesaurus</SourceCode>
      <SourceTermType>SY</SourceTermType>
    </VocabularySource>
  </SourceInformation>
  <ReviewStatus>Reviewed</ReviewStatus>
</OtherName>

Note that:

1. The SourceTermType values are different

2. Only one of the blocks has a SourceTermID element

Perhaps you and I are using different definitions of the word "duplicate." From Merriam-Webster:

Definition of duplicate

1. consisting of or existing in two corresponding or identical parts or examples <duplicate invoices>

2. being the same as another <duplicate copies>

Perhaps you and I are using different definitions of the word "duplicate." From Merriam-Webster:

I think we're on the same page. If you look at my comment above, I did acknowledge that the issue may be because of differences in the "Source Types" and you also additionally confirmed the differences in the "SourceTermID". I do see that they are different and we may have to continue to deal with it but I am not so sure how useful they are in processing the term documents. I'll ask Mary if the SourceTermID and the Source Term Type data are needed for processing the term documents.

You didn't say anything about the Definition Text though as they seem to have the same information and probably qualify as true triplicates for this particular document or is each definition mapped to each Other Name block?

I have been addressing the condition identified in the original request description (eliminating "repeated" OtherName blocks). I can implement more complicated logic, but I'll need more specific requirements for exactly which OtherName blocks I must eliminate. I can, for example, drop every OtherName block whose OtherTermName value has already been seen (ignoring case in comparison) in a previous OtherName block's OtherTermName child, or in the document's PreferredName element. I didn't mention definition text because the description for this issue only identified repeated OtherName blocks as the problem.

I just asked Mary about this and she is fine with not repeating other name blocks even in cases where the source type and source term ids are different. So, for this particular term under scrutiny, you can display only the first Other Name block and ignore the other two others. Would that take care of the repeated definition blocks also? Or I need to modify the ticket to add the definition blocks?

You need to modify the ticket to tell me exactly what you need the import software to do.

I have modified the original request. Please let me know if you need additional information.

Here are examples of the kinds of questions I need answers to in a complete specification of requirements for this sort of request.

1. If the other term name repeats the document's preferred name, do you want the other term block?

2. Is case significant in these comparisons of the name strings?

3. Should leading or trailing space be included or ignored in these comparisons?

4. Should the software ignore differences in internal white space (for example, two spaces versus one)?

1. Yes.
2. No, case is not significant.
3. They should be ignored.
4. Yes.

The logic has been modified as requested. Please test this very thoroughly to ensure that the software is doing exactly what you want it to. C123897 has been re-imported as CDR779386.

The import tool appears to be failing with the following error message (after clicking the import button)

<error>Failure parsing concept: Space required after the Public Identifier, line 1, column 47</error>

It seems the same error message is on PROD as well. I wonder if it has anything to do with HTTPS protocol issue.

Nothing to do with this ticket or with HTTPS. Their service is down. I'll report the problem.

FNLCR acknowledged that they broke our use of their API by turning off the URL we were using. I was unable to find any announcement of the switch on their announcement listserv. I put in a workaround for the problem on DEV and imported C29378 on that tier.

FNLCR did indicate that they might look into an approach which would eliminate the volatility of their API URLs.

Verified on QA.