From the guidelines
:

Naming Conventions

Different entities with the same name (for example, two artists named "John B") should be entered as "John B" and "John B (2)". The (2) is not part of the name but is used to distinguish the two names. If you need to create a third, use (3) and so on. Never swap about the suffixes, once an entity is designated a numerical suffix, the entity must remain with that suffix. The suffix has no relation to popularity or historical order.

Are suffixes necessary to distinguish credits and works with the same name on Bookogs? Unlike on Discogs, credits and works can have the same name but different numbers, so it doesn't seem that suffixes serve any useful purpose here.

The problem is that when you're adding a credit, if an identical credit exists in the database, the system will automatically match to that entry, even if you choose to "create" the credit, so you're forced to add something to the name to create a new entry.

Of course, there is always the option of removing the suffix afterwards. It will still remain as a separate entry.

It also seems that currently the suffixes are used more to help with the search - for example in the submission form the Work field only displays titles. If the search/display was improved, of course there would be less need for them.

We have also deviated from the guidelines, we're using other things than numbers too in certain cases.

These are the most recent discussions that are related to this topic:
https://www.bookogs.com/forum/530564-credit-name-indentifiers
https://www.bookogs.com/forum/524866-poems-with-the-same-name-by-one-poet

OK, thanks, I hadn't seen those discussions. Increasing the information displayed when searching would be major improvement.

It is possible to avoid having to rename a credit/work by creating it directly first, via https://www.bookogs.com/add/credit and https://www.bookogs.com/add/work

I'd also noticed some variety in the distinguishing descriptions already, e.g. https://www.bookogs.com/credit/65566-david-sylvian vs. https://www.bookogs.com/credit/272552-david-sylvian-musician - that, like your suggestions about collection/story in the other thread, could also work.

I'd also noticed some variety in the distinguishing descriptions already

Yes, I think most of us agree, that additional info is better than the numbering system. We (or at least some of us + kalli) agreed that it is allowed to use both ways (numbering or description) until a final decison is made.

Increasing the information displayed when searching would be major improvement.

Agreed, and it could make the suffixes mostly redundant.

For Works it should be already relatively easy, as Works do have dedicated fields for data that is commonly used for identification (author, year).

It could also include the form to avoid the Collection/Short Story suffixes, though that would require a new field, and/or the genre list issue sorted out as that's where they are at the moment.

Credits are a different kind of beast as we have so many different types of credits (persons, companies, imprints, subjects, series, etc.) which is why an Entity Type field might be a good start.

It is possible to avoid having to rename a credit/work by creating it directly first

True, but like renaming afterwards it does create an extra step, possibly multiple extra steps depending on the publication.

At one point I did experiment with the suffixless entries quite a bit, but most of them have been updated to include a suffix, mostly by other users... :-)

Agreed, and it could make the suffixes mostly redundant.

Maybe, if users would care about additional info ;-)

But even if they do:
Let's have a look at this entry ---> https://www.bookogs.com/work/471647-love

There are at least three poems from Herbert with this title.

The only way to distinguish them is a suffix (the first line).
Yes, you could add these things to the notes. Then you would have to click through all of these poems to find the correct one.

With the suffix you'll find them even with the autofill method.

As long as we don't have better solutions, a suffix is the best way to distinguish variants.

Maybe, if users would care about additional info ;-)

I think they would care more if the data was used and displayed somehow. But in general, the data will come with time. Our active userbase is still relatively small, and a lot of users are more focused on submitting books.

As long as we don't have better solutions, a suffix is the best way to distinguish variants.

Of course, and I was merely thinking out loud how we could improve the situation. Manually adding suffixes is not really ideal either. It will have to do for the time being, but I hope we can eventually get rid of it, and find a more sophisticated and "smarter" way to deal with the problem.

The problem is that when you're adding a credit, if an identical credit exists in the database, the system will automatically match to that entry, even if you choose to "create" the credit

Looks like this has been rolled back, not sure if intentionally... While the downside is that it creates duplicates if the same credit is "created" multiple times on a new submission, at the moment it's possible to create an identical entry without a suffix.

The bug can be always avoided by creating the credit before submitting the publication.

mirva wrote:

Looks like this has been rolled back, not sure if intentionally... While the downside is that it creates duplicates if the same credit is "created" multiple times on a new submission, at the moment it's possible to create an identical entry without a suffix.

Yes, this bug has been fixed. That is to say if you select create a credit with that name will be created (regardless of whether an identically named credit already exists).

But like you spotted it will create an identically named credit multiple times if it is listed more than once. For instance if a new credit is both an author and an editor. We are working on a fix for this.

This is all great news. :-)

But like you spotted it will create an identically named credit multiple times if it is listed more than once. For instance if a new credit is both an author and an editor. We are working on a fix for this.

This bug should now be fixed as well. Let us know if you run into any further problems with it.

Also just released is a bit more detail when linking works to books. The dropdown should now show the author of the work too, hopefully that will help to distinguish between works. Perhaps it would be good to show the year there as well too?

For credits I'm not sure what would be the best way to help people disambiguate between different credits with the same name. Perhaps credits should have date fields (born/died for people, founded/started for companies or other entities) and that could be shown in the card/dropdown view as well?

kalli wrote:

The dropdown should now show the author of the work too, hopefully that will help to distinguish between works.

Yes, it will. A lot. What is this, Christmas? :D

kalli wrote:

Perhaps it would be good to show the year there as well too?

It wouldn't hurt. It would especially help with some of the cases where one author has written works with the same name, as well as with some anonymous works.

kalli wrote:

For credits I'm not sure what would be the best way to help people disambiguate between different credits with the same name. Perhaps credits should have date fields (born/died for people, founded/started for companies or other entities) and that could be shown in the card/dropdown view as well?

Sounds good to me, at least. Locations would be useful too, but the dates are probably more important.

As we have so many types of credits there are some credits the dates won't work for, like some subjects. But I don't know how to solve that issue... other than tag them as 'Subject'. :P

mirva wrote:

Sounds good to me, at least. Locations would be useful too, but the dates are probably more important.

As we have so many types of credits there are some credits the dates won't work for, like some subjects. But I don't know how to solve that issue... other than tag them as 'Subject'. :P

Yes. We've been thinking about credits a bit, it would probably be good to have more structured data there too. In addition to dates Type would probably be one and would maybe have options like person, group, company, subject etc. Locations would be really cool too.

And now that I'm thinking out loud relationships would be awesome (a was member of b, x started y) but that's probably a bit out there still :)

Type would probably be one and would maybe have options like person, group, company, subject etc. Locations would be really cool too.

Sounds great. We need some flexibility for this Type field, since we have so many different credit types.

And thanks for the enlargement of the submission formular. Much better now.

indy133 wrote:

Sounds great. We need some flexibility for this Type field, since we have so many different credit types.

Agreed - both that the Type field sounds great and that there needs to be some flexibility. Depending on what options there will be, there might be also need to use multiple tags on some entities.

kalli wrote:

And now that I'm thinking out loud relationships would be awesome (a was member of b, x started y) but that's probably a bit out there still :)

That sounds great too. Feel free to think out loud more often - it's always nice to hear what's going on behind the scenes, even if it is just random ideas. :-)

The dropdown should now show the author of the work too, hopefully that will help to distinguish between works. Perhaps it would be good to show the year there as well too?

Another thought - the 'form' of the Work (novel, short story, collection, etc.) would be really useful too, for cases like:
https://www.bookogs.com/work/411683-bestiario-collection
https://www.bookogs.com/work/505137-bestiario-short-story

But it would probably require the genres and forms to be separated somehow, at least on the Work pages. Also would need some additions as for example "collection" is not on the list.

Login or Register to post a reply to this topic.