On 15 August 2018 at 18:32, Stas Malyshev wrote:
>> I tried searching for a few DOIs today which are string properties
>> (i.e. 10.1371/JOURNAL.PCBI.1002947) and didn't get any results.
>
> Statements are indexed, but you have to use haswbstatement with specific
> property to look for them.
Hi!
> I tried searching for a few DOIs today which are string properties
> (i.e. 10.1371/JOURNAL.PCBI.1002947) and didn't get any results.
Statements are indexed, but you have to use haswbstatement with specific
property to look for them.
> Is this the phabricator task for
> this:
Is this indexing now complete?
I tried searching for a few DOIs today which are string properties
(i.e. 10.1371/JOURNAL.PCBI.1002947) and didn't get any results.
Is this the phabricator task for this:
https://phabricator.wikimedia.org/T163642 ?
Cheers,
Marielle
On Sat, Jul 28, 2018 at 2:29 PM
Thanks a lot for looking into this, Stas!
On Thu, Jul 26, 2018 at 11:49 PM Stas Malyshev wrote:
> So, we have two questions:
> 1. Do we want to enable indexing for all item properties? Note that if
> you just want to find items with certain statement values, Wikidata
> Query Service matches this
Hi!
> * I would really like dates (mainly, born/died), especially if they work
> for "greater units", that is, I search for a year and get an item back,
> even though the statament is month- or day-precise
This is something I've been thinking about for a while, mainly because
the way we index
Hi!
> I could definitely see a usecase for 1) and maybe for 2). For example,
> let's say i remember that one movie that Rutger Hauer played in, just
> searching for 'movie rutger hauer' gives back nothing:
>
> https://www.wikidata.org/w/index.php?search=movie+rutger+hauer
>
> While Wikipedia
On 27/07/2018 18:34, Stas Malyshev wrote:
Hi!
* I would really like dates (mainly, born/died), especially if they work
for "greater units", that is, I search for a year and get an item back,
even though the statament is month- or day-precise
What would be the use case for this?
The use
Hi!
> * I would really like dates (mainly, born/died), especially if they work
> for "greater units", that is, I search for a year and get an item back,
> even though the statament is month- or day-precise
What would be the use case for this?
--
Stas Malyshev
smalys...@wikimedia.org
Le ven. 27 juil. 2018 à 14:00, James Heald a écrit :
> +1 with Magnus on years of birth and death
> (but perhaps /only/ years of birth and death, or close surrogates eg
> years of baptism and burial, and inception or publication date for
> things, otherwise the search specificity would become
Please, any one let me know about Wikidata project because I dont know
about this.
On Fri, Jul 27, 2018 at 5:29 PM, James Heald wrote:
> +1 with Magnus on years of birth and death
> (but perhaps /only/ years of birth and death, or close surrogates eg years
> of baptism and burial, and inception
+1 with Magnus on years of birth and death
(but perhaps /only/ years of birth and death, or close surrogates eg
years of baptism and burial, and inception or publication date for
things, otherwise the search specificity would become useless with too
many other 'significant event' dates)
I
Hi, and thanks for working on this!
My subjective view:
* We don't need P2860/P1433 indexed, at least not at the moment
* I would really like dates (mainly, born/died), especially if they work
for "greater units", that is, I search for a year and get an item back,
even though the statament is
I could definitely see a usecase for 1) and maybe for 2). For example,
let's say i remember that one movie that Rutger Hauer played in, just
searching for 'movie rutger hauer' gives back nothing:
https://www.wikidata.org/w/index.php?search=movie+rutger+hauer
While Wikipedia gives back quite a
Hi!
Today we are indexing in ElasticSearch almost all string properties
(except a few) and select item properties (P31 and P279). We've been
asked to extend this set and index more item properties
(https://phabricator.wikimedia.org/T199884). We did not do it from the
start because we did not want
14 matches
Mail list logo
