Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons

[Thad Guidry]

James,

It looks like a lot of that phabricator issue was around Taxons ?  For the
Poodle to show a class of Mammal...

Seems like many of these could be answered if someone responded to
https://www.wikidata.org/wiki/User:Danyaljj on their last question about if
an "OR" could be used with linktype with gas:service ... where no one gave
an answer to their final question comment here:
https://www.wikidata.org/wiki/Wikidata:Request_a_query/Archive/2017/01#Timeout_when_finding_distance_between_two_entities

I tried myself to answer that question and find either Parent Taxon OR
Subclass of a Poodle, but couldn't seem to pull it off using gas:service
and 1 hour of trial and error in many forms, even duplicating the program
twice ...

http://tinyurl.com/yb7wfpwh

#defaultView:Graph
PREFIX gas: 

SELECT ?item ?itemLabel
WHERE {
  SERVICE gas:service {
gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
gas:in wd:Q38904 ;
gas:traversalDirection "Forward" ;
gas:out ?item ;
gas:out1 ?depth ;
gas:maxIterations 10 ;
gas:linkType wdt:P279 .
  }
  SERVICE gas:service {
gas:program gas:gasClass "com.bigdata.rdf.graph.analytics.SSSP" ;
gas:in wd:Q38904 ;
gas:traversalDirection "Forward" ;
gas:out ?item ;
gas:out1 ?depth ;
gas:maxIterations 10 ;
gas:linkType wdt:P171 .
  }

  SERVICE wikibase:label {bd:serviceParam wikibase:language
"[AUTO_LANGUAGE],en" }
}


On Thu, Sep 27, 2018 at 5:24 PM Stas Malyshev 
wrote:

> Hi!
>
> > Apparently the Wikidata hierarchies were simply too complicated, too
> > unpredictable, and too arbitrary and inconsistent in their design across
> > different subject areas to be readily assimilated (before one even
> > starts on the density of bugs and glitches that then undermine them).
>
> The main problem is that there is no standard way (or even defined small
> number of ways) to get the hierarchy that is relevant for "depicts" from
> current Wikidata data. It may even be that for a specific type or class
> the hierarchy is well defined, but the sheer number of different ways it
> is done in different areas is overwhelming and ill-suited for automatic
> processing. Of course things like "is "cat" a common name of an animal
> or a taxon and which one of these will be used in depicts" adds
> complexity too.
>
> One way of solving it is to create a special hierarchy for "depicts"
> purposes that would serve this particular use case. Another way is to
> amend existing hierarchies and meta-hierarchies so that there would be
> an algorithmic way of navigating them in a common case. This is
> something that would be nice to hear about from people that are
> experienced in ontology creation and maintenance.
>
> > to be chosen that then need to be applied consistently?  Is this
> > something the community can do, or is some more active direction going
> > to need to be applied?
>
> I think this is very much something that the community can do.
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons

[Stas Malyshev]

Hi!

> Apparently the Wikidata hierarchies were simply too complicated, too
> unpredictable, and too arbitrary and inconsistent in their design across
> different subject areas to be readily assimilated (before one even
> starts on the density of bugs and glitches that then undermine them).

The main problem is that there is no standard way (or even defined small
number of ways) to get the hierarchy that is relevant for "depicts" from
current Wikidata data. It may even be that for a specific type or class
the hierarchy is well defined, but the sheer number of different ways it
is done in different areas is overwhelming and ill-suited for automatic
processing. Of course things like "is "cat" a common name of an animal
or a taxon and which one of these will be used in depicts" adds
complexity too.

One way of solving it is to create a special hierarchy for "depicts"
purposes that would serve this particular use case. Another way is to
amend existing hierarchies and meta-hierarchies so that there would be
an algorithmic way of navigating them in a common case. This is
something that would be nice to hear about from people that are
experienced in ontology creation and maintenance.

> to be chosen that then need to be applied consistently?  Is this
> something the community can do, or is some more active direction going
> to need to be applied?

I think this is very much something that the community can do.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons

[James Heald]

This recent announcement by the Structured Data team perhaps ought to be 
quite a heads-up for us:


https://commons.wikimedia.org/wiki/Commons_talk:Structured_data#Searching_Commons_-_how_to_structure_coverage

Essentially the team has given up on the hope of using Wikidata 
hierarchies to suggest generalised "depicts" values to store for images 
on Commons, to match against terms in incoming search requests.


i.e.  if an image is of a German Shepherd dog, and identified as such, 
the team has given up on trying to infer in general from Wikidata that 
'dog' is also a search term that such an image should score positively with.


Apparently the Wikidata hierarchies were simply too complicated, too 
unpredictable, and too arbitrary and inconsistent in their design across 
different subject areas to be readily assimilated (before one even 
starts on the density of bugs and glitches that then undermine them).


Instead, if that image ought to be considered in a search for 'dog', it 
looks as though an explicit 'depicts:dog' statement may be going to be 
needed to be specifically present, in addition to 'depicts:German Shepherd'.


Some of the background behind this assessment can be read in
   https://phabricator.wikimedia.org/T199119
in particular the first substantive comment on that ticket, by Cparle on 
10 July, giving his quick initial read of some of the issues using 
Wikidata would face.


SDC was considered a flagship end-application for Wikidata.  If the data 
in Wikidata is not usable enough to supply the dogfood that project was 
expected to be going to be relying on, that should be a serious wake-up 
call, a red flag we should not ignore.


If the way data is organised across different subjects is currently too 
inconsistent and confusing to be usable by our own SDC project, are 
there actions we can take to address that?  Are there design principles 
to be chosen that then need to be applied consistently?  Is this 
something the community can do, or is some more active direction going 
to need to be applied?


Wikidata's 'ontology' has grown haphazardly, with little oversight, like 
an untended bank of weeds.  Is some more active gardening now required?


  -- James.



---
This email has been checked for viruses by AVG.
https://www.avg.com


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Semantic annotation of red links on Wikipedia

[Maarten Dammers]

Hello,

On 27-09-18 01:16, Andy Mabbett wrote:

On 24 September 2018 at 18:48, Maarten Dammers  wrote:


Wouldn't it be nice to be able to make a connection between the red link on
Wikipedia and the Wikidata item?

This facility already exists:


https://en.wikipedia.org/wiki/Template:Interlanguage_link#Link_to_Reasonator_and_Wikidata
You seem to have done some selective quoting and selective reading. I 
addressed this in my original email:


On 24-09-18 19:48, Maarten Dammers wrote:
Where to store this link? I'm not sure about that. On some Wikipedia's 
people have tested with local templates around the red links. That's 
not structured data, clutters up the Wikitext, it doesn't scale and 
the local communities generally don't seem to like the approach. 
That's not the way to go. 

James also shared some links related to this.

Maarten




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata