Spinster added a comment.
In T282719#7088419 <https://phabricator.wikimedia.org/T282719#7088419>, @John_Cummings wrote: > Hi Sandra > > I've updated the description to include the FRBR model as the basis for creating and matching items. Is it logic to say that new items the based on ISBN number (or other similar ID) should be Instance='edition' in Wikidata? No, you're trying to simplify something that is not that simple. On Wikipedia, which only uses text strings, I guess it's fine to take an ISBN number and then use a database to look it up and retrieve strings of text to build up a (single) reference. On Wikidata, where we are dealing with multilingual structured data, a 'book' is a cluster of sometimes dozens of multilingual layered entities. To make it very clear, as I think I didn't succeed in doing that with my earlier comment: I think it is NOT a good idea to ask for a tool for this. It's not simple matter that should be automated. This is stuff that needs knowledgeable human review. If someone has a ISBN number and wants to 'have that ISBN on Wikidata', they should need to do at least the following checks (and this list is non-exhaustive; I'm actually not a librarian so I will probably miss important things and get some things wrong): - Is there already any work-level and/or edition-level item that corresponds with the book? If so, any new items need to correspond correctly with the existing ones. If not, new items need to be created for both levels. - A check needs to happen whether the ISBN is of a translation. Maybe we already have Wikidata items for the (original language) work, and/or for an edition of a translation in another language. If that is the case, correct connections need to be made. - The book needs *both* a work-level item and an edition-level item. (This is exactly what FRBR is about.) - Both the work item and the edition item need the correct statements in the right place: author, publisher, date of publication and other metadata. Correctly. I don't know of any centralized databases that get this stuff right where we can retrieve this; this step probably needs deeper human research than just a check with a (any) database. Worldcat is (in my experience) pretty messy at this point so please do NOT use Worldcat as a sole source. - If lookups on Wikidata need to happen for the right author and publisher, that needs to be done _with care_ - if the author, is, say, named John Johnson where we have dozens of people with a similar name, a thorough check is needed to make sure the right one is chosen. In my experience, it is always best to actually go on Wikidata and do a bit of (non-tool) research at this point, because there may be items for humans with just initials or with a slightly different spellings that can't be caught by a tool. - If an item for the author/publisher is not found, should a new one be created? I'm not sure - there's so much opportunity for introduction of errors and duplicates here. Let me state it very clearly: I'm not a fan of this task at all. I think describing books on Wikidata is simply too complex for a single-purpose tool. If describing books correctly is an intricate piece of reality that needs a few years of education in library science, then it's not something that we can magically simplify on Wikidata by 'toolifying' it. TASK DETAIL https://phabricator.wikimedia.org/T282719 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Spinster Cc: Seppl2013, Fuzheado, Pigsonthewing, Gamaliel, Spinster, Rhagfyr, Antoine2711, Jklamo, NavinoEvans, Aklapper, John_Cummings, Invadibot, maantietaja, Mohammed_Sadat_WMDE, Akuckartz, apaskulin, Nandana, lucamauri, Zambujo, Lahi, Gq86, valerio.bozzolan, GoranSMilovanovic, Chicocvenancio, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Izno, Wikidata-bugs, aude, Daniel_Mietchen, Jhernandez, jayvdb, Mbch331, bd808, Krenair, Tgr
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org