| Cparle updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
Option 1a
Perhaps we could pass a regex to the `haswbstatement` keyword?
Option 2
WeImplement 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 2 is tricky to implement, won'tand may not return exactly correct data, but would probably be more performant than option 3
...
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?
Option 2
WeImplement 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 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 wayOption 2 is tricky to implement, won'tand may not return exactly correct data, but would probably be more performant than option 3
...
TASK DETAIL
EMAIL PREFERENCES
To: Cparle
Cc: Aklapper, Ramsey-WMF, Cparle, Lahi, PDrouin-WMF, Gq86, E1presidente, SandraF_WMF, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, V4switch, LawExplorer, Susannaanas, Wong128hk, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331
Cc: Aklapper, Ramsey-WMF, Cparle, Lahi, PDrouin-WMF, Gq86, E1presidente, SandraF_WMF, GoranSMilovanovic, QZanden, EBjune, Tramullas, Acer, V4switch, LawExplorer, Susannaanas, Wong128hk, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
