| CommunityTechBot updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
26570726f6475636520796f757220627567207573696e67206120726563656e742076657273696f6e206f662074686520736f6674776172652c20746f2068652077696b6920636f6e74656e74206c616e67756167652e0a0a5468616e6b20796f752e0a546167730a436865636b557365720ad70a436f6e6e65637465642d4f70656e2d48657269746167652d42617463682d75706c6f61647320285241c42d4b4d425f315f323031372d3032290ad70a54616d696c2d53697465730ad70a47616d6570726573730ad70a48617368746167730ad70a4a4144450ad70a4b6172746f456469746f720ad70a4c616e67756167652d323031382d4170722d4a756e650ad70a4e65772d456469746f722d457870657269656e6365730ad70a4d61696c0ad70a5443422d5465616d0ad70a53756273637269626572730a4465736372697074696f6e20507265766965770a436f6e74656e77a6f6e652073657474696e6720696e20796f75722070726f66696c652c20636c69636b20746f207265636f6e63696c652eThe **inscription** property refers to ‘inscriptions, markings and signatures on an object' and is of type ‘monolingual text’
When used as a qualifier with 'depicts' it refers to markings on the thing-that-is-depicted - example from wikidata https://www.wikidata.org/wiki/Q1136099 (see depicts > Province of New York > inscription, etc.)
The example I've been using to model this conceptually is band t-shirts - an image could depict a t-shirt with 'The Rolling Stones' written on it, and a user might want to find all images containing pictures of Rolling Stones t-shirts
I can think of 3 different ways of implementing this, all with drawbacks/tradeoffs
Option 1
We can store the qualifier in the normal way like this `P180=Q131151[P1682=The Rolling Stones]` (see T193407), in which case we would only be able to find **exact matches**. For example searching for `haswbstatement:P180=Q131151[P1682=Stones]` won't match `P180=Q131151[P1682=The Rolling Stones]`.
Option 1a
Perhaps we could pass a regex to the `haswbstatement` keyword? Would require changes to the mapping of the `statement_keywords` field
Option 2
Implement a specific elasticsearch solution just for this qualifier - for example we could store the inscription in a fulltext field, which would mean a partial match would work. It'd be tricky to do, because we'd need to treat one qualifier differently to all the others both when we were indexing and when we're searching. Also if we did it this way I'm not sure how to store the fact that the inscription relates to a particular 'depicts' tag (or even if that'd be possible) - so someone could try and search for pictures containing Rolling Stones t-shirts and some of their results would contains blank t-shirts plus some //other// object with the text 'The Rolling Stones' inscribed on it.
Option 3
Another possible approach is to use the Wikidata Query Service (WDQS) to run a SPARQL query, and then use the ids as a filter for an elasticsearch query - basically we'd ask WDQS for all pictures depicting a t-shirt inscribed with 'The Rolling Stones', take all the resulting IDs, and then search elasticsearch for anything else we wanted to search for but only among the (max 1000) IDs we got from WDQS.
Note that this option depends on T194401
-----
Option 1 is easiest, but only does exact matches unless the regex idea (option 1a) works, which might be difficult to implement on the frontend in a user-friendly way
Option 2 is tricky to implement, and may return some incorrect data, but would probably be more performant than option 3
Option 3 is in-between, implementation-wise. Probably the slowest to run, results will be more accurate than option 2 but because of limitations passing data between WDQS and elasticsearch there will be edge cases where no results will be returned even if appropriate results exist.. This option depends on T194401
-----
Wikidata currently contains **7** items with depicts statements that have inscription qualifiers out of a total of ~70k items with depicts statements (~0.01%)
When used as a qualifier with 'depicts' it refers to markings on the thing-that-is-depicted - example from wikidata https://www.wikidata.org/wiki/Q1136099 (see depicts > Province of New York > inscription, etc.)
The example I've been using to model this conceptually is band t-shirts - an image could depict a t-shirt with 'The Rolling Stones' written on it, and a user might want to find all images containing pictures of Rolling Stones t-shirts
I can think of 3 different ways of implementing this, all with drawbacks/tradeoffs
Option 1
We can store the qualifier in the normal way like this `P180=Q131151[P1682=The Rolling Stones]` (see T193407), in which case we would only be able to find **exact matches**. For example searching for `haswbstatement:P180=Q131151[P1682=Stones]` won't match `P180=Q131151[P1682=The Rolling Stones]`.
Option 1a
Perhaps we could pass a regex to the `haswbstatement` keyword? Would require changes to the mapping of the `statement_keywords` field
Option 2
Implement a specific elasticsearch solution just for this qualifier - for example we could store the inscription in a fulltext field, which would mean a partial match would work. It'd be tricky to do, because we'd need to treat one qualifier differently to all the others both when we were indexing and when we're searching. Also if we did it this way I'm not sure how to store the fact that the inscription relates to a particular 'depicts' tag (or even if that'd be possible) - so someone could try and search for pictures containing Rolling Stones t-shirts and some of their results would contains blank t-shirts plus some //other// object with the text 'The Rolling Stones' inscribed on it.
Option 3
Another possible approach is to use the Wikidata Query Service (WDQS) to run a SPARQL query, and then use the ids as a filter for an elasticsearch query - basically we'd ask WDQS for all pictures depicting a t-shirt inscribed with 'The Rolling Stones', take all the resulting IDs, and then search elasticsearch for anything else we wanted to search for but only among the (max 1000) IDs we got from WDQS.
Note that this option depends on T194401
-----
Option 1 is easiest, but only does exact matches unless the regex idea (option 1a) works, which might be difficult to implement on the frontend in a user-friendly way
Option 2 is tricky to implement, and may return some incorrect data, but would probably be more performant than option 3
Option 3 is in-between, implementation-wise. Probably the slowest to run, results will be more accurate than option 2 but because of limitations passing data between WDQS and elasticsearch there will be edge cases where no results will be returned even if appropriate results exist.. This option depends on T194401
-----
Wikidata currently contains **7** items with depicts statements that have inscription qualifiers out of a total of ~70k items with depicts statements (~0.01%)
TASK DETAIL
EMAIL PREFERENCES
To: CommunityTechBot
Cc: Ramsey-WMF, Cparle, AndyTan, Zylc, 1978Gage2001, Lahi, PDrouin-WMF, Gq86, E1presidente, SandraF_WMF, herron, GoranSMilovanovic, Chicocvenancio, alanajjar, QZanden, EBjune, Tbscho, Tramullas, Acer, V4switch, LawExplorer, Lea_WMDE, Mattias_Ostmar-WMSE, JJMC89, Jseddon, Ryuch, Mkdw, RuyP, JEumerus, Trizek-WMF, Susannaanas, KasiaWMDE, 0x010C, srodlund, Wong128hk, Luke081515, grin, Bsadowski1, Aschroet, mys_721tx, Jane023, Wikidata-bugs, Snowolf, Base, matthiasmullie, aude, Huji, Gryllida, jayvdb, Ricordisamoa, Tobi_WMDE_SW, Lydia_Pintscher, Fabrice_Florin, Raymond, revi, scfc, He7d3r, Romaine, Steinsplitter, Matanya, Mbch331, Jay8g, Glaisher, Krenair, chasemp
Cc: Ramsey-WMF, Cparle, AndyTan, Zylc, 1978Gage2001, Lahi, PDrouin-WMF, Gq86, E1presidente, SandraF_WMF, herron, GoranSMilovanovic, Chicocvenancio, alanajjar, QZanden, EBjune, Tbscho, Tramullas, Acer, V4switch, LawExplorer, Lea_WMDE, Mattias_Ostmar-WMSE, JJMC89, Jseddon, Ryuch, Mkdw, RuyP, JEumerus, Trizek-WMF, Susannaanas, KasiaWMDE, 0x010C, srodlund, Wong128hk, Luke081515, grin, Bsadowski1, Aschroet, mys_721tx, Jane023, Wikidata-bugs, Snowolf, Base, matthiasmullie, aude, Huji, Gryllida, jayvdb, Ricordisamoa, Tobi_WMDE_SW, Lydia_Pintscher, Fabrice_Florin, Raymond, revi, scfc, He7d3r, Romaine, Steinsplitter, Matanya, Mbch331, Jay8g, Glaisher, Krenair, chasemp
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
