On 23/07/2020 22:26, Hay (Husky) wrote:
Awesome, i'm really happy we finally have at least a start of a
functioning query service.
For now, the two things that i guess would be helpful for most query writers:
1) A way to make ImageGrid work without resorting to the clunky
Special:FilePath hack
2) A nicer way to query Wikidata information without using federation.
I guess 2) might be a bit more difficult, but it might definitely be
something to consider.
Kind regards,
-- Hay
IMO, the best way to avoid the hack of having to construct the
Special:FilePath urls would be to have these simply available as
triples, so the standard way to get an image with this sort of URL
would just be
sdc:M1234567 ?relation commons:filename.jpg
for some ?relation to be determined.
Also, as User:Mfchris84 has noted on the talk page, another reason to
desire such triples is to make it possible to map from the values of
wikidata properties like P18 ("image") and its friends, which are of the
form commons:filename.jpg to the corresponding M-IDs, so that
structured data about the files can be accessed.
At the moment going from commons:filename.jpg -> M-ID -> sdc data is
not straightforward.
Is there a particular reason that schema:contentUrl was chosen to
point to URLs of the form
<https://upload.wikimedia.org/wikipedia/commons/q/q1/filename.jpg>
rather than
<http://commons.wikimedia.org/wiki/Special:FilePath/filename.jpg>
that WDQS uses?
Is the specific location useful? (Is it even stable?) Or would it make
more sense to use the established url form for these links, as used in
WDQS ?
As to Hay's (2), being able to use the SERVICE for label lookup in WCQS
without requiring explicit federation to WDQS would be a nice step forward.
But overall I am *hugely* impressed by what the team has rolled out.
Thank you so much!
-- James.
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
