#bookbrainz

I formatted and read through https://wiki.musicbrainz.org/User:CatCat/BB_For...

I'll try to fill up information where needed

CatQuest: Mind I I take on some of the suggestions you had (for example "softcover" as the generic term that includes paperbacks), or would you prefer I make a separate copy?

what do you mean now? to edit the wikipage? go a head and edit it! :D

Yes, that. OK, thanks :)

Mr_Monkey: oh thanks for filling in blanks. so it turns out that BARD is a sort of audio-book braille thing, so I think valid af

the flexibound probably too

as for diecut and bookclub ones, I feel those are "special cases" of already excisting paperback/hardback etc things

I have bookclub books too, and i've seen oftne that these have two sets of isbn printed, one for "not bookclub" and one "for the bookclub"

imho "quality of paper/binding" doesn't really make "a new format"

this seems more things useful for tagging/notes/annotation/series/collectios imho

I also read in the community post how "journal" is bascially "magazine for scientists" but here is the scrub: how does it look different?

would saying "Magazine/Journal" as a type wok jsut a swell for the physical format?

it seems saying "scientific journal" is a better worktype or similar

possiby

same with "sheet music" that's *what it countains* not "what it physically lookslike/binding"

in my experience these are usualyl pamphlets or actual binded books

i dunno how works would work here though. for sheet music, is it the author of the music who is a writer?

should each song/movement be it's own work?

reosarevok feedback here too

(everyone here as well)

seems "promo" together with flyers pamplets posters and "single paper" type things

i recall bookogs people where pretty unanimous in wanting to limit the amound of types too, not having so many very detailed ones that could be confused wit eachother

maybe i'll have time to cook dinner before everything too for once :D

I do like the idea of keeping relevant sub-types (I think "book club" for example is useful in the collectors circles) as long as we can select a more generic type like "paperback".

hm.

i'd aonly like those if they wher multiple choice maybe

i think thi is a question for the community too

Multiple choice as in a field for type and a different field for sub-type?

yes /like in mb/one type and multiple subtypes?

something could very well be both "bookclub" *and* die cute

cut*

Hm, I see. Parrt of the issue here is that some formats are a mix of physical attributes and content

*Exactly*

i think physsical attribute sohudl be what we go for in "edition format" and if we have *content* it's either work or some other edition attribute

Yeah, that's a theme throughout that list of definitions, but it doesn't really irk me too much; if they are generally considered different formats in the industry, then fine by me.

There are a few ambiguous examples like sheet music

not by me though. "the indistry" isn't good enough ! :V

There's both a notion of format and content

yes

i would definitly not have "sheet music" in this list

it's squarly work type imho

or edition type (not format!)

Well…

edition format shudl be.. something that differenciates editions.

if it is expected that *every* edition shoudl have that "type" it's useless for "edition format" in this way

edition-group type maybe

Hm. Good point.

So tentatively, maybe some of those formats that include some notion of content should be EG types instead.

I think that could make a lot of sense

yea i've not agaisnt that idea actulaly

hii

Hi here BenOckmore !

Hey :D

heey we're getting the band backtogeter! :D

"What happened to the BluesMobile"?

it was a refrence to that phinius & ferb episode but

that was probably a rfrence to that agin so :D

Ah, I went the Blues Brothers road…always :)

:D i need to rewatch that. i was jsut a kid when i saw it :D

I hope this doesn't end the same way as Blues Brothers :o

right now we are talknig about expanding edition formats https://wiki.musicbrainz.org/User:CatCat/BB_For...

you guys can talk typesript anyway, i need ot go dry my hair /make dinner on time for once

glad to have you around ben :)

I'll be open for that TS discussion in 10-15min :)

CatQuest: looks like some of those will want nesting. Good ideas, there are definitely a lot of uncontroversial ones that could be added

Mr_Monkey: going to head out and get some late lunch, so would 20-25 minutes be good for you?

Absolutely, take your time

ah I can't take credit for any but the "my addition" ones ;)

it's https://community.metabrainz.org/t/matching-boo... and https://community.metabrainz.org/t/formats-cred...

and discussion in here

Mr_Monkey: ping

pong !

So I've gone through the PR again, and really have no questions.

I had misunderstood `?type` as `param?` and that's that :)

Ahh ok, excellent

And I agree this PR isn't meant to sovle all the typing problems, so I think it's mergeable

OK, if you're happy to merge, once it's closed I'll get on to rebasing the next set of changes and get a new PR in

I'll go ahead and approve the PR, unless you think there's anything else needed apart from rebasing

OK

Just a heads up, I'm also working on replacing ES with SOLR, and I've got most of the backend done, so now just need to hook up the routes. The results are pretty comparable to what you get on the live site now

Oh, really,‽ Nice !

How do you find the complexity of the setup?

It's not too bad, I took the default config and and went into schemaless mode, indexed all of our entities, then took the resulting generated schema and tweaked it a bit. There's a lot more that could be done, and it's certainly not as complex as the MusicBrainz search server, but the existing ES implementation is so simple that replacing it doesn't need a complex solution

Hm, there's one more thing for PR 538: I think the CI pipelin isn't ready for typescript yet, could that be? I see this error on travis:

That's really nice to hear !

I'll look into that...

I've done some progress recently with ES and it has improved the search results a fair bit, but ditching it is still a goal, so it's reassurign to hear it's achievable

Thanks for tackling that too! You've been super helpful with these projects and I'm really thankful!

Yeah, I saw that. I've copied the existing search/autocomplete strategies into Solr, so for search it's using 1-3 character trigrams, and for autocomplete, 2-10 character edge N-grams

And also searching through all aliases and the disambiguation

Neat

Looking forward to discovering what else is possible with Solr

And I've also indexed a couple of additional properties for each entity that we can use implement some filtering (e.g. female authors born after 1900)

As a first step for that, we could have a selectable "advanced query mode" similar to what MB has, which would allow users to write plain Solr standard query syntax

It's a good poweruser feature

A tabulated search interface with filtering would be ideal, one day.

I've replicated the CI error locally, will debug now and hopefully have a fix in so we can merge in time for the weekly meeting :D

Awesome :)

Aha, so the problem is, I was only running build/lint for testing, and not test, so mocha isn't set up for TypeScript... just looking into that, it doesn't look too tricky though

So the question is, should we run babel on the src to make it work with mocha, and get the full babel transformation applied, or just run ts-node to strip out the types?

[18:53] <BenOckmore> Just a heads up, I'm also working on replacing ES with SOLR,

👏 👏 👏

I think using ts-node will save some precious time in the testing, and I can't see a reason why that would be detrimental. Can you?

OK, let's try that

Ah, looks like we're already running babel for the tests, so I'll just tweak that

It might be only running for JS/JSX files and passing through TS/TSX untouched

Ah, that could be it.

I forget how what we run to get the tests ready, apparently :)

Faceted search for Solr looks like a good candidate fro front-end search interfaces; here's one of the examples: http://resources.huygens.knaw.nl/womenwriters/v...

And React components library: https://www.npmjs.com/package/solr-faceted-sear...

Looks nice, faceting + filtering could be quite an improvement over the current search

The tricky bit apart from the actual work implementing it will be to make sure it works for non-JS users, since search is a public-facing part of the site

Some useful but more limited interface

Mr_Monkey: fixed the test issue, now fixing some test failures that were previously hidden

👍

Seems like it's issues in my environment, will assume that it'll be fixed in CI...

I'm hoping to switch to Docker locally soon so that'll clear it up

I'm a proponent of the "push and find out" method.

oh no

I usually do that too tbh. That's why we run tests on PRs anyway :D

.. and that's why we always have to fix your mistakes or?..

:D

Mr_Monkey: pushed 2 new commits to fix the issue, and rebased: https://github.com/bookbrainz/bookbrainz-site/p...

great, thanks !

Also, reading the history, I agree that react-select is a PITA xD

I'm gonna roll it in now, long day today, let's talk more formats tomorrow afternoon

Mr_Monkey: CI passing, happy for me to merge?