Bug #13327

Feature #13279: Add relationship type to authority record relations CSV import and export

Problem: the relations import CSV should start with the subjectAuthorizedFormOfName column

Added by Peter Van Garderen 5 months ago. Updated 4 months ago.

Status:VerifiedStart date:05/20/2020
Priority:MediumDue date:
Assignee:Peter Van Garderen% Done:

0%

Category:CSV import
Target version:Release 2.6.0
Google Code Legacy ID: Tested version:
Sponsored:Yes Requires documentation:Yes

Description

If an Authority record relationships CSV file contains multiple rows for a single authority record (e.g. row 1: Boss 1 controls Employee 1a; row 5: Boss 1 is the superior of Employee 1b). Then only the last row for that record in the CSV file (e.g. row 5) will get written to the AtoM database, ignoring the earlier rows.

actor_relations.csv Magnifier (323 Bytes) Mike Cantelon, 05/21/2020 03:10 AM

parent_relations.csv Magnifier (594 Bytes) Peter Van Garderen, 05/25/2020 07:59 PM


Related issues

Related to Access to Memory (AtoM) - Bug #13326: Problem: blank "Related" searches returns both sides of c... Verified 05/20/2020

History

#1 Updated by Peter Van Garderen 5 months ago

  • Description updated (diff)

#2 Updated by Peter Van Garderen 5 months ago

  • Parent task deleted (#13279)

#3 Updated by Peter Van Garderen 5 months ago

  • Parent task set to #13286

#4 Updated by Mike Cantelon 5 months ago

  • File actor_relations.csvMagnifier added
  • Status changed from New to Feedback
  • Assignee changed from Mike Cantelon to Peter Van Garderen

I wasn't able to replicate this when importing via the GUI using the attached example CSV (with three actors: "Dad", "Suzy", and "Billy").

#5 Updated by Peter Van Garderen 5 months ago

  • Status changed from Feedback to Verified

I couldn't replicate again either with the attached relations.csv file and a new one I created so closing this issue. BTW I like the move of the "relationType" column between the "objectAuthorizedFormOfName" and "subjectAuthorizedFormOfName" columns. That reads a lot more naturally now and we (I) should update the sample template accordingly.

#6 Updated by Mike Cantelon 5 months ago

Dan and I were talking about the naming/ordering of those columns... I think he wants "subjectAuthorizedFormOfName" to take the place of "objectAuthorizedFormOfName" and visa versa. I might have to update the logic to make this work given that these will be the opposite of what they are in the DB.

#7 Updated by Dan Gillean 5 months ago

Peter, I would love your take on this as well.

I reordered the columns in the CSV exmaple to implement what I thought was already happening:

subjectAuthorizedFormOfName | relationType | objectAuthorizedFormOfName

To me, this implies that the relation type will be applied to the subject - the object will get the converse term (which may be self-reciprocal). Example:

subjectAuthorizedFormOfName | relationType | objectAuthorizedFormOfName
-----------------------------------------------------------------------
Example Corporation         |   controls   |    Example Person

... means that the Example Corporation should have the "controls Example Person" relation, and the Example Person would have the converse, "is controlled by Example Corporation"

I did one test when reordering the columns and got what I expected, but now I'm not sure if Mike and I are misunderstanding each other or if I'm misunderstanding the funtionality. If that's not how it works currently, then I would suggest changing it - following the linked-data (and general English syntax) of subject-predicate-object makes the most intiuitive sense to me, rather than object-predicate-subject.

However, I'm open to discussing this! Curious to hear your thoughts - and your take on what the current behavior is, as someone who has tested this a lot more than I!

#8 Updated by Peter Van Garderen 5 months ago

In my testing I wasn't paying close attention to the column names other than verifying that the value in the first, left-most column was the one "owning" the relationship or yes, in linked data parlance, the "subject" of the relationship. I only noticed a difference when the relationType column was moved in between the two AuthorizedFormsOfName which made things much more readable. I do agree now, however, with Dan that the correct English (and syncing with Linked Data practice) would be to name the left-most column "SubjectAuthorizedFormOfName" and the last column "ObjectAuthorizedFormOfName".

I also ran a new test using this new order in the import CSV. I used:

subjectAuthorizedFormOfName | relationType | objectAuthorizedFormOfName
Ghost 1                     |  haunts      | Victim A
Ghost 2                     |  haunts      | Victim B
Ghost 3                     |  haunts      | Victim C

The relations imported correctly. Ghosts 1, 2, and 3 "haunts" Victim A, B, and C respectively. And conversely Victims A, B, and C "is haunted by" Ghost 1, 2, and 3. So it looks like nothing needs to change in the import code. We just need to update our sample CSV and docs.

#9 Updated by Dan Gillean 5 months ago

Great! That's what I thought as well.

In that case, we may not need to do anything at all (unless you are talking about project samples?). The CSV example updates I pushed the other day already reordered the cols - you can see them here:

I think the only change we'll have to make is: if we decide to remove legacyId from import and export for the relationships, then we'll need to also update the template example to remove the legacyId column I added.

Thanks for testing, Peter!

#10 Updated by Peter Van Garderen 5 months ago

Okay, I may have spoken too soon. I just ran a test for the GUI relations CSV import INDEXING bug (which was fixed). In doing so, I used the new order we discussed (my CSV file is attached). However, this time, the relationships were turned around in AtoM.

So I had:

subjectAuthorizedFormOfName | relationType           | objectAuthorizedFormOfName
Father1                     |  is the parent of      | Child1a
Father1                     |  is the parent of      | Child1b
Father1                     |  is the parent of      | Child1c
Father2                     |  is the parent of      | Child2a
Father2                     |  is the parent of      | Child2b
Father2                     |  is the parent of      | Child2c

And AtoM now shows "Child1a is the parent of Father1", "Father1 is the child of Child1a", etc.

So it looks like we have more to change in AtoM's import code if we want to use "subjectAuthorizedFormOfName" as the first column.

#11 Updated by Peter Van Garderen 5 months ago

  • Subject changed from Problem: only the last relationship type in a CSV file is imported to Problem: the relations import CSV should start with the subjectAuthorizedFormOfName column

Since the original issue in the original name of this ticket turned out to be a non-issue and it has since evolved into a new requirement, I've changed the name of this issue to reflect this subject -> relation -> object ordering we've been discussing.

At the same time, whether to keep the legacyId column or drop it continues to be an related, outstanding issue.

#12 Updated by Peter Van Garderen 5 months ago

  • Parent task deleted (#13286)

#13 Updated by Peter Van Garderen 5 months ago

  • Parent task set to #13279

#14 Updated by Peter Van Garderen 5 months ago

  • Status changed from Verified to In progress
  • Assignee changed from Peter Van Garderen to Mike Cantelon

#15 Updated by Peter Van Garderen 5 months ago

  • Related to Bug #13326: Problem: blank "Related" searches returns both sides of converse relationship added

#16 Updated by Mike Cantelon 5 months ago

  • Status changed from In progress to Code Review
  • Assignee deleted (Mike Cantelon)

#17 Updated by Mike Cantelon 4 months ago

  • Status changed from Code Review to QA/Review

Merged into qa/2.6.x.

#18 Updated by Peter Van Garderen 4 months ago

  • Status changed from QA/Review to Verified
  • Assignee set to Peter Van Garderen
  • Requires documentation set to Yes

Will require update to example CSV templates as well.

Also available in: Atom PDF