Feature #13279: Add relationship type to authority record relations CSV import and export
Problem: the relations import CSV should start with the subjectAuthorizedFormOfName column
|Assignee:||Peter Van Garderen||% Done:|
|Target version:||Release 2.6.0|
|Google Code Legacy ID:||Tested version:|
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.
#4 Updated by Mike Cantelon 5 months ago
- File actor_relations.csv 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
- File parent_relations.csv added
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.