CK data on combined work becomes ineditable and inaccessible
Talk Bug Collectors
Join LibraryThing to post.
This topic is currently marked as "dormant"—the last message is more than 90 days old. You can revive it by posting a reply.
1rsterling
(Repeating this report to get a bug tracker.)
When there's CK data on a work that's combined into another book, sometimes that data carries through to the combined book, but often it does not. Instead, the CK data on the other work page (the one that does not win out in combination) often remains, but stuck in the system somewhere with no clear way to access or edit it.
Some examples:
http://www.librarything.com/commonknowledge/search.php?q=spam&f=21&uid=m...
(Pay attention to the work numbers: most or all of these works with this canonical title have been combined into another work, and now there's no interface to get those canonical titles out of the system)
Another, non-spam, example:
http://www.librarything.com/commonknowledge/search.php?q=guermantes&f=21&...
The second result there is for work number 42585, which was the old work number for The Guermantes Way, and which had that canonical title entered. However, 42585 was (mistakenly) combined into Swann's Way (work number 18169) in that big Proust combining mess. So now, there's some CK for The Guermantes Way that is still in the system somewhere, attached to 42585, which has been combined with Swann's Way (18169), but not visible or editable on the Swann's Way work page.
When there's CK data on a work that's combined into another book, sometimes that data carries through to the combined book, but often it does not. Instead, the CK data on the other work page (the one that does not win out in combination) often remains, but stuck in the system somewhere with no clear way to access or edit it.
Some examples:
http://www.librarything.com/commonknowledge/search.php?q=spam&f=21&uid=m...
(Pay attention to the work numbers: most or all of these works with this canonical title have been combined into another work, and now there's no interface to get those canonical titles out of the system)
Another, non-spam, example:
http://www.librarything.com/commonknowledge/search.php?q=guermantes&f=21&...
The second result there is for work number 42585, which was the old work number for The Guermantes Way, and which had that canonical title entered. However, 42585 was (mistakenly) combined into Swann's Way (work number 18169) in that big Proust combining mess. So now, there's some CK for The Guermantes Way that is still in the system somewhere, attached to 42585, which has been combined with Swann's Way (18169), but not visible or editable on the Swann's Way work page.
2timspalding
So, what's the answer?
3infiniteletters
Throwing out options, some of which I don't support.
1. Notice on Combination screen that an author being combined has CK.
2. Preventing combination of authors with CK
3. Automatically combining both author's CK into the main author.
4. Displaying that a combined author has CK, and having a show link or something, so it can be seen and edited.
Of course, the next question is: what happens when an author with CK is separated?
1. Notice on Combination screen that an author being combined has CK.
2. Preventing combination of authors with CK
3. Automatically combining both author's CK into the main author.
4. Displaying that a combined author has CK, and having a show link or something, so it can be seen and edited.
Of course, the next question is: what happens when an author with CK is separated?
4timspalding
1-2.
Separation works as now. It stays with larger one.
Separation works as now. It stays with larger one.
6rsterling
Since work numbers become obsolete and inaccessible once combined into another work, it seems to me like the answer is:
First, reproduce ALL CK from the obsolete work number to the new work number (ideally giving the original person credit, but that's not such a big deal, since they'll get credit for the original add anyway).
And, second, delete all CK from the old work number.
I don't know what the rule is for which work number becomes dominant and which becomes obsolete, but I'm assuming there's some predictable system there.
First, reproduce ALL CK from the obsolete work number to the new work number (ideally giving the original person credit, but that's not such a big deal, since they'll get credit for the original add anyway).
And, second, delete all CK from the old work number.
I don't know what the rule is for which work number becomes dominant and which becomes obsolete, but I'm assuming there's some predictable system there.
8rsterling
7 - meaning 4. Displaying that a combined work has CK, and having a show link or something, so it can be seen and edited?
That would be fine too, but there could be a lot of work numbers combined together, and right now there's no way to display the combined works or a combination history per work. (Come to think of it, a combination/separation history per work could be very helpful....)
ETA - or did you mean message 4? If so, then it makes sense to me that separation means things stay with the larger work, given the way the work system works -- i.e. since separation creates a new work number rather than reverting to a previous work number. It's annoying when there are mistaken combinations, to have to separate then copy and paste CK over, but I can't see any other way around it unless you radically change the way separation works.
That would be fine too, but there could be a lot of work numbers combined together, and right now there's no way to display the combined works or a combination history per work. (Come to think of it, a combination/separation history per work could be very helpful....)
ETA - or did you mean message 4? If so, then it makes sense to me that separation means things stay with the larger work, given the way the work system works -- i.e. since separation creates a new work number rather than reverting to a previous work number. It's annoying when there are mistaken combinations, to have to separate then copy and paste CK over, but I can't see any other way around it unless you radically change the way separation works.
9keristars
3> If you're really talking about authors, and not works, there's an RSI thread from last weekend you might want to contribute to.
But otherwise, works and authors are different beasts, especially since it's not uncommon to combine authors only temporarily.
But otherwise, works and authors are different beasts, especially since it's not uncommon to combine authors only temporarily.
10geitebukkeskjegg
Adding to 4: Displaying that a combined author has CK, and having a show link or something, so it can be seen and COPIED.
Preferably copy to combined work by a one-click-per-item OR one-click-copy-all function.
Preferably copy to combined work by a one-click-per-item OR one-click-copy-all function.
11KingRat
Taking an idea from my genealogy program, I'd suggest a merge as part of the combination:
Before the merge is finalized, a CK page comes up that shows what's in one work, and what's in the other work, and gives options to list both, use the left, or use the right. (It could auto-combine CK items that are the same from both, obviously.)
(For geeks, think about it as if it were a code merge.)
The user clicks on the items to keep, then hits submit, and the combination is finalized.
Before the merge is finalized, a CK page comes up that shows what's in one work, and what's in the other work, and gives options to list both, use the left, or use the right. (It could auto-combine CK items that are the same from both, obviously.)
(For geeks, think about it as if it were a code merge.)
The user clicks on the items to keep, then hits submit, and the combination is finalized.
12geitebukkeskjegg
Slightly OT: Please note that what message 10 or 11 describes would also be a good approach for copying CK data across language barriers/sites.
14eromsted
I'm wondering if this CK search result is an example of the bug.
I've deleted all of the Everyman's Library entries from the regular series field and the series page is now empty. The result list for the search above did shrink as I went, but it did not go away.
Note: I'm not referring to the Pocket Poets or Children's Classics results, just the plain Everyman's Library.
I've deleted all of the Everyman's Library entries from the regular series field and the series page is now empty. The result list for the search above did shrink as I went, but it did not go away.
Note: I'm not referring to the Pocket Poets or Children's Classics results, just the plain Everyman's Library.
16eromsted
Hmm. The address itself has quotation marks in it and I don't seem to be able to make it into a working link.
It's a CK series search for "Everyman's Library" with some fiddling to get to the real second page. See my other bug report on that issue.
You can paste the following after www.librarything.com and hit return.
/commonknowledge/search.php?q="Everyman's+Library"&f=23&startNum=50&stepNum=49
It's a CK series search for "Everyman's Library" with some fiddling to get to the real second page. See my other bug report on that issue.
You can paste the following after www.librarything.com and hit return.
/commonknowledge/search.php?q="Everyman's+Library"&f=23&startNum=50&stepNum=49
17rsterling
Yeah, that's what happened here. If you hover over the link to the work, and look at the work number, then click on the link, you'll see that it takes you to a different work number. This information was entered for a work that was later combined into another work.
There's some kind of weird and slightly convoluted URL workaround that someone showed me once that can delete CK information even in these cases, but I'd have to dig up my notes on it to remember how it works.
There's some kind of weird and slightly convoluted URL workaround that someone showed me once that can delete CK information even in these cases, but I'd have to dig up my notes on it to remember how it works.
18timspalding
Update on why this isn't fixed yet (see http://www.librarything.com/topic/107331).
CH and I are planning a fix to the language issue in CK. After that, I want to make it impossible to combine works with the same CK fields filled in. But I can't do that until there's a language-flipper way to see all the CK data from just one site.
CH and I are planning a fix to the language issue in CK. After that, I want to make it impossible to combine works with the same CK fields filled in. But I can't do that until there's a language-flipper way to see all the CK data from just one site.
20EveleenM
#18
After that, I want to make it impossible to combine works with the same CK fields filled in.
Do you mean any of the same CK fields? That would be pretty disastrous for a lot of combining!
For a lot of the series I've worked on (such as travel guides), the works to be combined may have three or four different authors, or no author at all. The only way to line them up is to put a series label on them. If we can't combine works with series CK filled in, it will make setting up series incredibly difficult.
Then there's the canonical name. Working on the Analog magazine series http://www.librarything.com/series/Analog+Science+Fiction+and+Fact , I found that some issues had dates, some had issue numbers, some had volume numbers (arabic numerals) and some volume numbers (roman numerals). Have a look at the combination page for John W. Campbell http://www.librarything.com/combine.php?author=campbelljohnw - the only guaranteed way to even find all the matching issues with different numbering is to give them all the same canonical name (which of course can be deleted afterwards).
Please leave things so that works with identical series and canonical names can be combined. I know you're going to do more with it, but author combination is pretty miserable at the moment with the present display of author search results. I'd hate to find that series combination got messed up as well.
After that, I want to make it impossible to combine works with the same CK fields filled in.
Do you mean any of the same CK fields? That would be pretty disastrous for a lot of combining!
For a lot of the series I've worked on (such as travel guides), the works to be combined may have three or four different authors, or no author at all. The only way to line them up is to put a series label on them. If we can't combine works with series CK filled in, it will make setting up series incredibly difficult.
Then there's the canonical name. Working on the Analog magazine series http://www.librarything.com/series/Analog+Science+Fiction+and+Fact , I found that some issues had dates, some had issue numbers, some had volume numbers (arabic numerals) and some volume numbers (roman numerals). Have a look at the combination page for John W. Campbell http://www.librarything.com/combine.php?author=campbelljohnw - the only guaranteed way to even find all the matching issues with different numbering is to give them all the same canonical name (which of course can be deleted afterwards).
Please leave things so that works with identical series and canonical names can be combined. I know you're going to do more with it, but author combination is pretty miserable at the moment with the present display of author search results. I'd hate to find that series combination got messed up as well.
21keristars
20> I have to agree about works and authors being different kettles of fish. I like the idea of not being able to combine authors with different data in the same CK fields, since there's no way to change the data without separating them, but I don't see why with works the CK shouldn't just pull through to the top, especially if the data is identical.
(my preference for authors is to be able to view the CK of a sub-author and the gilding on that pony would be if it could be edited from there. but definitely not have the ck combined onto a single author page...this is really different from the work CK problem, though, I think)
(my preference for authors is to be able to view the CK of a sub-author and the gilding on that pony would be if it could be edited from there. but definitely not have the ck combined onto a single author page...this is really different from the work CK problem, though, I think)
22EveleenM
(digressing onto authors rather than works)
#21
I like the idea of not being able to combine authors with different data in the same CK fields, since there's no way to change the data without separating them
The deal-breaker on that for me is that there's no sure way of telling which author page will come out on top in a combination. The thought of carefully blanking 15 or 20 items and then finding that that's the page that comes out on top really puts me off. Furthermore, if the balance between two combined author pages is tipping back and forth as new copies are added, you could end up having to separate them, blank one and fill in the other on a regular basis. With a CK-heavy page, that would be a huge amount of time-wasting.
my preference for authors is to be able to view the CK of a sub-author and the gilding on that pony would be if it could be edited from there.
That's the way to go, I think.
#21
I like the idea of not being able to combine authors with different data in the same CK fields, since there's no way to change the data without separating them
The deal-breaker on that for me is that there's no sure way of telling which author page will come out on top in a combination. The thought of carefully blanking 15 or 20 items and then finding that that's the page that comes out on top really puts me off. Furthermore, if the balance between two combined author pages is tipping back and forth as new copies are added, you could end up having to separate them, blank one and fill in the other on a regular basis. With a CK-heavy page, that would be a huge amount of time-wasting.
my preference for authors is to be able to view the CK of a sub-author and the gilding on that pony would be if it could be edited from there.
That's the way to go, I think.
23keristars
(still digressing!)
22> The deal-breaker on that for me is that there's no sure way of telling which author page will come out on top in a combination. The thought of carefully blanking 15 or 20 items and then finding that that's the page that comes out on top really puts me off.
Right, that's why I said "different data". If it's the same, then it doesn't matter, but if the fields are different, then there must be a reason: either error (so one side needs to be fixed) or they're different people and shouldn't be combined. No need to blank out one side!
But this way, if both sides have the same CK, then it doesn't matter which one comes out on top.
It does cause problems for combining authors in order to more easily combine works, though.
I made an RSI a few months ago on the topic, I should go find it...
ETA: http://www.librarything.com/topic/99806 - the RSI in question. At the time, I was messing around with Nationality a lot (this is before the new search) and getting frustrated with the badly formatted or just plain wrong CK data showing up in search, but being difficult to fix.
22> The deal-breaker on that for me is that there's no sure way of telling which author page will come out on top in a combination. The thought of carefully blanking 15 or 20 items and then finding that that's the page that comes out on top really puts me off.
Right, that's why I said "different data". If it's the same, then it doesn't matter, but if the fields are different, then there must be a reason: either error (so one side needs to be fixed) or they're different people and shouldn't be combined. No need to blank out one side!
But this way, if both sides have the same CK, then it doesn't matter which one comes out on top.
It does cause problems for combining authors in order to more easily combine works, though.
I made an RSI a few months ago on the topic, I should go find it...
ETA: http://www.librarything.com/topic/99806 - the RSI in question. At the time, I was messing around with Nationality a lot (this is before the new search) and getting frustrated with the badly formatted or just plain wrong CK data showing up in search, but being difficult to fix.
25jjwilson61
Or make a new way to be able to search for works to combine the way you can search for authors to combine, so you don't have to combine two authors that shouldn't be combined in order to combine a work.
27jjwilson61
I agree. In fact, why hold on to a complicated tree-structure of included authors. All that's really needed is a place in the author record to list all the other names that have been combined into it. A text field would do. And those combined names would still have to be indexed so they can be found in a search.
28lorax
27>
All that's really needed is a place in the author record to list all the other names that have been combined into it. A text field would do.
I think that would make author separation much, much harder than it currently is.
All that's really needed is a place in the author record to list all the other names that have been combined into it. A text field would do.
I think that would make author separation much, much harder than it currently is.
29jjwilson61
For author separation LT would just create a new author record put the name of the author being separated out into it and let the member decide if the CK should stay with the old author, go with the new author, or both. Additionally, you could allow multiple author names to be separated out at the same time so that you can separate out John Q Smith and John Quincy Smith from John Smith at the same time.
Since you won't be allowed to combine two authors that have different CK entries there shouldn't be a problem with co-mingled CK info to worry about on separation.
Since you won't be allowed to combine two authors that have different CK entries there shouldn't be a problem with co-mingled CK info to worry about on separation.
30lorax
29>
It's not the CK that's the problem, it's the works. If the original work->author mapping is lost, when they get separated it would be a major pain to regenerate.
As I understand it the situation now is basically
Pre-combination:
Author A:
---Work X
---Work Y
Author B:
---Work Z
---Work W
Post-combination:
Author A: (aka Author B:)
---Work X (Author A)
---Work Y (Author A)
---Work Z (Author B)
---Work W (Author B)
The work-to-subauthor assignments aren't shown by default, but because the data structure is still there in the original form, just aliased, it's not actually lost. So it's simple to recover the original form by separating. You're proposing throwing away that structure, though, so there's no longer a record that works Z and W were associated with author B pre-combination. (It could be recomputed from the book-level author data, I suppose, which is why it would just be harder than is is now, rather than impossible.)
It's not the CK that's the problem, it's the works. If the original work->author mapping is lost, when they get separated it would be a major pain to regenerate.
As I understand it the situation now is basically
Pre-combination:
Author A:
---Work X
---Work Y
Author B:
---Work Z
---Work W
Post-combination:
Author A: (aka Author B:)
---Work X (Author A)
---Work Y (Author A)
---Work Z (Author B)
---Work W (Author B)
The work-to-subauthor assignments aren't shown by default, but because the data structure is still there in the original form, just aliased, it's not actually lost. So it's simple to recover the original form by separating. You're proposing throwing away that structure, though, so there's no longer a record that works Z and W were associated with author B pre-combination. (It could be recomputed from the book-level author data, I suppose, which is why it would just be harder than is is now, rather than impossible.)
31jjwilson61
I see what you mean. It means that Tim would have to recompute the author for each book in the original author based on the work's editions on a separate action. I'm not sure that's not such a bad idea though, but for authors with lots of work it could cause a lot of work.
Tim could also add an original author field to each work record that would contain the name in text of the author a work had before combination. Then each work could be examined on separation and if it matched the author being split off it would be split off with it.
Tim could also add an original author field to each work record that would contain the name in text of the author a work had before combination. Then each work could be examined on separation and if it matched the author being split off it would be split off with it.
32timspalding
Jeremy. Still true?
34eromsted
That's only for authors, no? This bug is about CK on works. Specifically it's about the way trapped CK can show up in the CK search.
Click on the second link in the first message. Find the two canonical titles in English listed as "The Guermantes Way." Click on the links in the "What" column. You will be taken to the work page for Swann's Way. "The Guermantes Way" is not found on that page in the canonical title field and yet, as we saw, it shows up in the CK search.
Click on the second link in the first message. Find the two canonical titles in English listed as "The Guermantes Way." Click on the links in the "What" column. You will be taken to the work page for Swann's Way. "The Guermantes Way" is not found on that page in the canonical title field and yet, as we saw, it shows up in the CK search.
36conceptDawg
Just so it's been addressed: combining/separating works and authors has caused issues for CK since...well, forever. It's on my list to figure out but there just hasn't been a good time to re-engineer CK yet. It will come.
In the meantime, I'm going to mark this as deferred since we aren't going to "fix" it with the current design.
In the meantime, I'm going to mark this as deferred since we aren't going to "fix" it with the current design.
