Publisher's Series Question

Happened upon this group by chance — wish I had found it sooner, I've had a lot of series questions!

I'm migrating a collection from another source, wherein what LT calls 'publisher's series' and what LT calls 'series' are in the same field, and when viewing the entire collection at once they are in the same column. This is important especially for antique anthology collections, as they are shelved together based on the publisher's series they belong to.

Is a way there to indicate or 'turn on' a publisher's series for one's specific book so that it shows up on the book details and in the 'series' column of the collection?

Navigate to the series page, click the "Edit Series" button and "Basic Settings". The series type (regular or publisher) is the first item on that page.

>2 Felagund: Thank you for your response, but I think this affects the series globally, no? The series labels I want in this collection are 'publisher's series' and I don't want to mess that up for people who have copies outside of the antique set in this collection.

I only want it to display for the book in this collection, it wouldn't be true or correct for it to display for the whole work.

As an example, the collection holds an antique Shakespeare set; if I understand correctly, setting this as a series instead of a publisher's series would cause any person with a copy of Julius Caesar to show it being in a series with The Tragedy of Coriolanus. I'm wondering if there's a way to take a publisher's series and display it within only this collection.

Yes, series and publisher series are visible beyond your own collection. That's how they are intended to work:

1) Series: the information is applicable to all copies and editions of the book (for example The Fellowship of the Ring is volume 1 of The Lord of the Rings, regardless of publisher, translation, etc.).

2) Publisher Series: only relevant for some books combined into the work, but that's not a problem. It's labeled a **Publisher** Series precisely to distinguish from case 1.

There are detailed explanations in the LT wiki: https://wiki.librarything.com/index.php/Series

>5 Felagund: Okay, this is what I thought when I made the original post. So, is there a way there to indicate or 'turn on' a publisher's series for one's specific book so that it shows up on the book details and in the 'series' column of the collection?

No. You can enter it somewhere else. Other Call number might work since you say you want it for shelving.

>7 MarthaJeanne: That won't work unfortunately, as the 'other call number' is used for the call number. Thanks, anyway.

>6 GraceCollection:
It's really not necessary to do that. Books being associated with a publisher's series in the Librarything sense, while they are actual editions that were published somewhere else, is the normal and accepted behavior of this platform. It's not super intuitive, I agree, but it's not a problem in practice (assuming that was your concern).

>9 Felagund: My concern was that in this location, there are a lot of books that are organized by 'publisher's series.' In the previous system the collection was indexed in, these publisher's series were visible in the 'series' data field to any user viewing the collection. Here, because of 'publisher's series,' they aren't. I was hoping to find a way to make the appropriate 'publisher's series' visible for the cohesion of the collection.

In general, I'm wondering what publisher's series are even for if they can't be applied to individual books or visible within collections. What purpose do they serve if they cannot be associated with the metadata of individual entries?

When I saw 'publisher's series,' I assumed they functioned a little like covers: different ones could theoretically apply to an individual book, so when a user adds a work to their collection, they choose which (or in a 'publisher's series' case, if) one applies to their individual book. Then, if one is selected, it shows up and is visible in that collection, for the use of those browsing that collection.

Changing the cover (or publishing information, or heck, even the title) for a copy of Merchant of Venice in this collection is visible to whomever views the collection, but vitally, doesn't change anything for other users. As far as I've found, within an individual collection, 'publisher's series' can't be selected or become visible anywhere, so I don't really understand what purpose it serves.

>12 GraceCollection: Please remember that 'collection' has a specific meaning in LT. Using it to refer to your whole account is confusing.

People wanted a way to list what books were available in these publishers series, and Tim gave it to them. It doesn't do what you want, but it does at least some of what other people want. If it didn't the data wouldn't be there. Nobody would bother entering it if they didn't think it was helpful. Creating the kind of set up you want would require lots more staff, lots more computer power. Not going to happen. Tim and most of the users would prefer to keep LT free.

Speaking of collections. If you don't have too many of these, you could create a collection for each of these piblishers series, which would show you that they belong together.

Note that collections get hard to manage if you have more than about two dozen of them.

FWIW, I use tags for the few publisher series I really want to track in my catalogue, such as SF Masterworks, for instance.

Publisher series can be visible in your catalogue if you include the column. It's just not very useful without edition layer to recognize whether your copy belongs to one and which, so few if any people use it there. I do visit many publisher series pages to check what else is there even if I have only one or 2 books from it, so I find it useful even in its current form. If you want to track what in your catalogue belongs to a particular one, you do need to devise some system, whether it be tags, collections or something else.

>15 SandraArdnas: What you mention here may be the solution I'm looking for, would you mind going into a little more detail about what you mean by "edition layer"?

I'm certainly going to have to come up with some system, which is why I started by asking here, but unfortunately I don't think 'collections' will work, as there are too many publisher's series, and I would really rather avoid using tags for this, if at all possible. A lot of questions I ask about, I get directed to use tags, but without any form of grouping available, it's simply too unwieldy to put half a dozen different forms of metadata, each of which previously had its own field, all into a single field together.

>13 MarthaJeanne: Everything on the site uses computer power, including features which I don't happen to use, and including features which you don't happen to use, so I don't think it's really fair to say something's "Not going to happen," just because change requires computer power. The way I had previously assumed the 'publisher's series' worked was almost exactly like choosing which cover applies to one user's specific book. The cover feature requires computer power, but it was determined to be useful, so it exists, and that didn't cause such an increase in computing power that the site could no longer be free.

>17 GraceCollection: and 13

Just to prevent a possible misunderstanding: changes in the system don't require much computer power (in general). They require time and energy from human developers, while existing features do not (or not mich) unless there is a problem with them.

>18 Felagund: I've never worked with a database on the scale that LT has, so I don't know which features use more or less computing power than others to perform correctly. What I meant by "change requires computer power" is that I have discussed many ideas for new features or feature changes (especially in the site recommendations thread, which I no longer post in) and have been met time and time again with "that will never change/be implemented because it would require too much computing power" — even if the feature I had suggested would work exactly like a feature which already exists, like this whole 'publisher's series' as cover selection feature (which wasn't really a suggestion, just an explanation of how I had assumed a feature that already exists works).

Usually the computing power of any single aspect of a catalogue is fairly negligible (although, again, I haven't worked on the scale of LT so can't say that definitively about every feature that exists or is proposed), but many comments I have received in the past seem to imply any change in the site at all is going to require enough computing power to overload the servers and shut the whole thing down, while simultaneously seeming to imply that no currently implemented feature would ever possibly be in danger of coming close to that level. Sometimes seems to me to be a complaint about change rather than a measured response to any given proposal.

And of course I don't mean to imply that introducing new features doesn't require that a human program them in and work out bugs, but if they are programmers for LT, I would assume that to be part of their job description.

What I'm saying is: computer power has nothing to do with the issue at hand!* Let's all stop using these words in this context, immediately. It just confuses matters.

Now regarding human development time: the critial point is priorities. There are many pending requests for improvement https://www.librarything.com/ngroups/559/Recommend-Site-Improvements (as I guess you already know), as well as projects decided by LT staff for their own reasons. Regardless of job description, some tasks will happen sooner, some later, and some not at all. MarthaJeanne is apparently not optimistic about a possible evolution such as the one you expect. I kind of agree with them (based on a number of improvement requests that I consider very important but that have not been addressed for several years).

Edited to add:
*: at least until the issue has been properly analyzed by a technical specialist.

>16 GraceCollection: In order for the system to automatically recognize whether your copy is in a certain publisher series, it would need a whole new layer of data about different editions. As it is, there's a book layer, holding the data of individual copies in individual catalogues, and the work layer, which gathers data that apply to the work as a whole.

I very much doubt an edition layer is ever coming on LT. Aside from being a humongous developer project for a small team, it's dubious it is even feasible. If you have any experience with difficult decisions what constitutes one or 2 separate works, it will be clear why creating a system that recognizes and groups editions from various individual entries just gets too complex.

For individual use, using tags for a dozen different purposes is a non-issue, but I can see why you'd want to keep them single-purpose for a library used by patrons. In that case, you'd need some other way to keep track of publisher series of YOUR books. Comments, private comments if it doesn't need to be seen by patrons, are easily searchable and sortable, but depending on what you need this for there may be others. Including it in the Publication field, makes it searchable, but not sortable unless it's the first thing in the field. You can even append the series to the title if that is of high interest to patrons, not just the staff.

>21 SandraArdnas: Ah, from your comment I thought you meant there existed an edition layer that I hadn't figured out yet. I misinterpreted that, my apologies.

I don't think an edition layer would be necessary to change this feature, though. Works are connected already to publisher's series. In my mind the solution would be that the publisher's series column in an individual library is no longer just displaying the common knowledge list of publisher's series, but instead allows the user to select one publisher's series from those connected to the work (or to select 'blank'), maybe from a drop-down menu similar to the one for the media type of a book. Then, that single publisher's series is attached to the book in the same way a cover or media type is, and visible from guest view of the library (if the column is turned on). If someone doesn't want to use that feature in their library, it remains blank, and doesn't affect anything else. No edition layer necessary, in my opinion.

As >20 Felagund: wisely points out, LT staff is mysterious and unknowable has a priority list which we as users don't know. This may never happen, but it's interesting to problem solve. At least, I'm interested in problem solving it.

For the time being, I think I'll use titles, as comments are currently replacing a different data field that LT doesn't have. Those were both good suggestions, thank you. I am a little irked it will be in a different column than the series, but you win some, you lose some.

>22 GraceCollection: In my mind the solution would be that the publisher's series column in an individual library is no longer just displaying the common knowledge list of publisher's series, but instead allows the user to select one publisher's series from those connected to the work (or to select 'blank'), maybe from a drop-down menu similar to the one for the media type of a book. Then, that single publisher's series is attached to the book in the same way a cover or media type is, and visible from guest view of the library (if the column is turned on).

That sounds feasible, so you might consider making an RSI for that.

>23 SandraArdnas: The difference with covers is that once uploaded they cannot be changed or deleted. Since works can be removed from publisher series there would have to be a data structure built to connect the entry in the PS back to the books that include it. Or absent a data structure, a very expensive search through the database

>24 jjwilson61: Covers can be deleted. If I change mine AND no one else is using it, it is deleted. I expect a similar mechanism, meaning that if someone has book A attached to publisher series B, it should persist, while complete deletion is only possible if it is NOT attached to any books. But all of this is academic and beside the point unless someone actually makes the RSI, at which point it's up to developers to evaluate a) how desirable such a feature would be B) how implementable

I give free permission for someone else to put this in RSI, but I've dealt with enough hostility and misreading/misinterpretation/reading the title & reacting without seeming to have read anything I had written in the post, which often felt intentional, on every single post I've made there. I'm not posting in RSI any time soon, thank you.