spq_label() ?

[lvaudor]

Hey! What if we had a function spq_label() which we could call this way:

tib <- spq_init() %>%                              # Initialise requête puis
  spq_add("?film wdt:P31 wd:Q11424")  # Ajoute motif "?film est une instance de film"
  spq_add("?film wdt:P840 ?loc")            # Ajoute motif "?film a pour localisation narrative ?loc 
  spq_label(film, loc) %>%                      # Ajoute étiquettes pour film et loc
  spq_language("en,fr") %>%                 # Affiche les étiquettes en anglais, ou à défaut en français puis
  spq_head(n=10) %>%                         # Sélectionne les 10 premiers résultats puis
  spq_perform() 

(gathers in one call all labels rather than having them as argument in various spq_add calls)

This would not be too complicated to implement with your "table structured queries" (??) and we do not have to remove the .label argument of spq_add(), both could be available... What do you think?

[lvaudor]

Also, if we keep the .label argument, could we make it more "flexible" so it also accepts "variable" or even variable instead of "?variable"? As in: library(glitter) tib=spq_init() %>% spq_add("?prop wdt:P31 wd:Q18616576", .label="prop") %>% spq_perform() tib

or even

library(glitter) tib=spq_init() %>% spq_add("?prop wdt:P31 wd:Q18616576", .label=prop) %>% spq_perform() tib

Else, we could just throw a warning when .label="prop" instead of .label="?prop".

[maelle]

we do not have to remove the .label argument of spq_add()

Why not remove it?

[lvaudor]

Honestly, just in order not to break all examples as shown in previous talks

[lvaudor]

maybe we should just send a warning for now that .label is deprecated?

[maelle]

yes we could do it using lifecycle, deprecate it over time.

[maelle]

Query that works well for finding labels in a language if they exist

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?mayor ?mayor_label ?node ?place ?place_label ?species

WHERE {

?mayor wdt:P31 ?species.
?mayor p:P39 ?node.
?node ps:P39 wd:Q30185.
?node pq:P642 ?place.
OPTIONAL {
  ?mayor rdfs:label ?mayor_label.
  FILTER(!bound(?mayor_label) || lang(?mayor_label) IN ('de'))
}
OPTIONAL {
  ?place rdfs:label ?place_label.
  FILTER(!bound(?place_label) || lang(?place_label) IN ('de'))
}
VALUES ?species {wd:Q144 wd:Q146 wd:Q780}
SERVICE wikibase:label { bd:serviceParam wikibase:language "en".}
}

if having the FILTER inside the OPTIONAL really changes something, we need to implement it for spq_label()... and beyond?!

[maelle]

also interesting, the idea of coalescence https://opendata.stackexchange.com/questions/9618/wikidata-label-language-how-to-fallback-to-any-language

[maelle]

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?mayor (COALESCE(?mayor_label, "") as ?label) ?node ?place ?place_label ?species

WHERE {

?mayor wdt:P31 ?species.
?mayor p:P39 ?node.
?node ps:P39 wd:Q30185.
?node pq:P642 ?place.
OPTIONAL {
  ?mayor rdfs:label ?mayor_label.
  FILTER(lang(?mayor_label) IN ('nl'))
}
VALUES ?species {wd:Q144 wd:Q146 wd:Q780}
SERVICE wikibase:label { bd:serviceParam wikibase:language "en".}
}

but in any case it seems we need "Constraints in Optional Pattern Matching" = FILTER in OPTIONAL, so a filter we'd store in the triples df. We can add it for here, but I wonder what an interface would be for FILTER in OPTIONAL in spq_add().