Add tool wdcoord to get coordinates

[nichtich]

As described at #5 this adds dependencies which I find useful for the other tools too.

[maxlath]

This is already possible using qclaims: qclaims Q2112 P625
On the one hand I do love aliases ^^ on the other hand, I wonder if we won't end up with one alias for every property?

[nichtich]

First, there is a bug if you installed wikidata-cli globally:

$ qclaims Q2112 P625
Error: EACCES: permission denied, open '/usr/local/lib/node_modules/wikidata-cli/props/de.json'
    at Error (native) 
Context:
 undefined

I would expect qlaims not to require looking up a local file if property is already given by its id.

But also after this has been fixed, the result is

$ qclaims Q2112 P625
P625 [] coordinate location
copied to Clipboard: 

Looms like the output format of qclaims does not support coordinates. This could be improved by having special handlers for each Wikidata datatype, for instance to convert decimal coordinate to degree. So in general you are right, this could all be done in qclaims but only with additional extension. For instance

$ qclaims Q2112 P625
52.016666666667 8.5166666666667

$ qclaims Q2112 P625 --format degrees
52°01'0.00" 8°31'0.00"

For wikidata-item datatype instead of

$ qclaims Q1 P31
P31 [ 'Q1454986' ] instance of
copied to Clipboard: Q1454986

I would want

$ qclaims Q1 P31
Q1454986

And piped to qlabel:

$ qclaims Q1 P31 | qlabel
physical system

See also #4.

P.S: Maybe wdclaims is right (more-or-less) but I want the value instead of the full claim.

$ wd values Q2112 P625
52.016666666667 8.5166666666667

$ wd values Q2112 P625 --format degrees
52°01'0.00" 8°31'0.00"

Additional arguments and options to filter values with qualifiers and references.

[maxlath]

qclaims uses the local property file to generate the output with the properties labels:

P31 [ 'Q1454986' ] instance of

(the instance of part above)

Damn, I didn't see that "permission denied" message coming: I installed node with nvm which setups node modules in the home folder /home/username/.nvm/versions/node/v4.4.5/lib/node_modules/wikidata-cli/props/de.json. Would the solution be to create a dedicated folder in the user home (like /home/username/.wikidata-filter) where we would have the right to write anything that we need?
Fyi, another consumer of those properties files is wdprops and the properties are taken fresh out of the SPARQL endpoint: we got to cache that in some way to avoid spamming the endpoint with what starts to be a heavy query, thus the use of local files.

[nichtich]

How about moving the property cache functionalty to wikidata-sdk and store it in ~/.wikidata-sdk/? Having property names could also be useful to other tools. No matter where it is stored, the command should also work when property data is not available and just print

P31 [ 'Q1454986' ]

[maxlath]

wikidata-sdk should stay small enough so that one can include it in a web app without overthinking it, including the whole list of properties in one or several languages would clearly compromise that ;)

# current weight
32K wikidata-sdk.js
20K wikidata-sdk.min.js
12K wikidata-sdk.min.js.gz

88K en-props.js
72K en-props.min.js
32K en-props.min.js.gz

But if you see the need for features involving those files, we could have something like a wikidata-sdk-extra module dedicated to features requiring heavier assets

[nichtich]

I did not mean to include props in wikidata-sdk but lib/get_lang_props, lib/reset_properties, lib/fetch_properties. Web applications could make use of this feature to store properties in the browser cache.

[maxlath]

Hey @nichtich, I re-implemented wd coord as a partial of wd claims in c3281b0, so I close this PR