The qualifier information is now in the cell ; however this is not used for the queries endpoint.

Mentioned in SAL (#wikimedia-cloud) [2024-04-30T19:10:21Z] <wmbot~jeanfred@tools-sgebastion-10> Deploy 5a91a78, 864d518, c9b199 (T251008), 0dd731f

Ok, the code is now in a shape where I can do this. I’m only missing the SPARQL queries :) Let’s continue to take https://www.wikidata.org/wiki/User:Jean-Fr%C3%A9d%C3%A9ric/T251008 as example − what would be correct query for the last column?

For the positive query, this is pretty close:

SELECT DISTINCT ?entity ?entityLabel ?value ?valueLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  ?entity p:P669 ?prop .
  ?prop ps:P669 [] ; pq:P670 ?value
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

but it would not pick up the novalue. For "normal" Property Columns this is solved with using ?entity p:P669 ?prop . OPTIONAL { ?prop ps:P669 ?value }

For negative query, how about

SELECT DISTINCT ?entity ?entityLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  ?entity p:P669 ?prop .
  OPTIONAL {
    ?prop ps:P669 [] ; pq:P670 ?value.
  }
  filter (!bound(?value))
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

but i think this is also missing the novalue usecase − which for normal propertycolumn is done by MINUS { {?entity a wdno:P669 .} UNION {?entity wdt:P669 ?prop .} }

Any thoughts − maybe @VIGNERON or @LucasWerkmeister ?

For the positive query, I would suggest:

SELECT DISTINCT ?entity ?entityLabel ?value ?valueLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  ?entity p:P669 ?statement .
  { ?statement pq:P670 ?value . } UNION { ?statement a wdno:P670 . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

I renamed ?prop to statement since it’s less confusing IMHO; removed ?prop ps:P669 [] because IIUC you don’t actually want to filter for statements with a real main value (you also want to include novalue main statements); and I added the UNION to cover both “has P670 qualifier with real value or unknown value” and “has P670 qualifier with no value”. (Note that, if the main statement property and qualifier property are the same, then this becomes ambiguous since a wdno:P670 might be either the main snak or the qualifier being “no value”. You can in theory disambiguate it based on whether the statement also has a real main value under P670 or not, but it gets fiddly.)

I don’t understand the negative query yet. Are you looking for any items that have the main statement but not the qualifier? Or also items that don’t even have the main statement?

In T251008#9769788, @LucasWerkmeister wrote:

For the positive query, I would suggest:

SELECT DISTINCT ?entity ?entityLabel ?value ?valueLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  ?entity p:P669 ?statement .
  { ?statement pq:P670 ?value . } UNION { ?statement a wdno:P670 . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Thanks @LucasWerkmeister − will give it a try!

(Note that, if the main statement property and qualifier property are the same, then this becomes ambiguous since a wdno:P670 might be either the main snak or the qualifier being “no value”. You can in theory disambiguate it based on whether the statement also has a real main value under P670 or not, but it gets fiddly.)

I see, thanks for the note. I think this is unlikely enough as a modelling practice to not have to worry about it

I don’t understand the negative query yet. Are you looking for any items that have the main statement but not the qualifier? Or also items that don’t even have the main statement?

Hmmm, good question, had to think hard about it. The latter − all instances where the information is missing − whether just the qualifier is missing, or the main statement is missing.

In T251008#9771333, @JeanFred wrote:

I see, thanks for the note. I think this is unlikely enough as a modelling practice to not have to worry about it

👍

Hmmm, good question, had to think hard about it. The latter − all instances where the information is missing − whether just the qualifier is missing, or the main statement is missing.

I think this works:

SELECT DISTINCT ?entity ?entityLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  MINUS {
    ?entity p:P669 ?statement .
    { ?statement pq:P670 ?value . } UNION { ?statement a wdno:P670 . }
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

It currently finds both Q61638474 (has no “located on street”, permalink) and Q61638482 and Q61638497 (have “located on street” without “house number” qualifier, permalink permalink).

Also, slight refinement for the positive query:

SELECT DISTINCT ?entity ?entityLabel ?value ?valueLabel WHERE {
  ?entity wdt:P31 wd:Q28564,wd:Q11396180;wdt:P17 wd:Q55 .
  ?entity wdt:P361 wd:Q59961903 .
  ?entity p:P669 ?statement .
  { ?statement pq:P670 ?value . } UNION { ?statement a wdno:P670 . BIND("no value"@en AS ?valueLabel) }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

I added a BIND in the second UNION clause to make the label show “unknown value”. (I can’t test it, since none of the currently selected items have a novalue qualifier.)

Also, slight refinement for the positive query:

Will use that!

Another requirement I forgot to mention: integraality supports both p1/p2 (which we discussed) and p1/q2/p3. For example, P39/Q18558478/P580 is used on https://www.wikidata.org/wiki/Wikidata:WikiProject_every_politician/Italy/Coverage_by_term (see also the cookbook) How can we handle that? :)

Mentioned in SAL (#wikimedia-cloud) [2024-05-04T20:07:16Z] <wmbot~jeanfred@tools-sgebastion-10> Deploy 8ec2fec (T251008)