Re: [Wikidata-tech] Content negotiation

[Stas Malyshev]

Hi!

> For SELECT queries, the response format is
> application/sparql-results+xml by default (even without specifying the
> format parameter), and the only other format I could persuade it to
> offer was JSON (with format=json).

Yes, the query supports only xml and json formats now.

> For CONSTRUCT queries (the useful sort :-) ), you need format=rdf (or
> format=application/rdf+xml), which returns a lovely RDF XML document. 
> If you omit the format parameter, you get a 'File not found' error.

For these, you can do both XML and JSON too. What you could do is run
CONSTRUCT query, which would return JSON having three fields - subject,
predicate and object - and then make a simple script in any language
that reads that JSON and processes it to output, say, ntriple-formatted
RDF. That would be not hard.

As this is just starting the SPARQL story, it would be nice to see
suggestions about how we could format the output better... Maybe some
export options in the GUI. JSON has all the data, but some processing is
required to get CONSTRUCT produce some useful RDF serialization. At
least for now.

BTW it's open source (the GUI too) so pulls to
https://github.com/wikimedia/wikidata-query-rdf/tree/master/gui may also
be the way to do it ;)
-- 
Stas Malyshev
smalys...@wikimedia.org

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

[Wikidata-tech] Wikidata API breaking changes

[Addshore]

Hi all!


We have some breaking API changes that will soon be deployed to wikidata.org.


The deployment date should be: 9th September 2015 (just under 2 weeks)


The change making the breaks an be found at:

https://gerrit.wikimedia.org/r/#/c/227686/


The breaking changes are:

 - XML output aliases are now grouped by language
 - XML output may no longer give elements when they are empty
 - XML any claim, qualifier, reference or snak elements that had an
'_idx' element will no longer have it
 - ALL output may now give empty elements, ie. labels when an entity has none


If you want to see a wikipage explaining these changes take a look at:

https://www.wikidata.org/wiki/User:Addshore/API_Break_September_2015


If you have any questions regarding these breaking changes please ask!


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

Re: [Wikidata-tech] Content negotiation

[Lydia Pintscher]

On Thu, Aug 27, 2015 at 12:49 PM, Richard Light
 wrote:
> Hi Daniel,
>
> Thanks for updating the page.  I think, however, you have been a bit
> over-zealous in changing the URLs.  The sentence:
>
> For example, the concept URI of Douglas Adams is
> http://www.wikidata.org/wiki/Special:EntityData/Q42.
>
> should I think use the concept namespace http://www.wikidata.org/entity/.

Daniel actually had it right in the wikitext source but somehow the
translation grabled it. I fixed it now.


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

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

Re: [Wikidata-tech] Content negotiation

[Richard Light]

Hi Daniel,

Thanks for updating the page.  I think, however, you have been a bit 
over-zealous in changing the URLs.  The sentence:


For example, the /concept URI/ of Douglas Adams is 
http://www.wikidata.org/wiki/Special:EntityData/Q42.


should I think use the concept namespace http://www.wikidata.org/entity/.

No problems about any confusion: I see it as a useful learning 
exercise.  For example, I was also going to comment on your 
double-redirect strategy, but having checked it in Vapour I then re-read 
the Cool URIs document and realised that it is an impeccable 
implementation of one of the strategies described there.  So now I know 
more than I did yesterday. :-)


Best wishes,

Richard

On 27/08/2015 11:37, Daniel Kinzler wrote:

Hi Richard!

You are right, the Data access documentation did not properly distinguish
between concept URI and data URL. I have fixed this now. URLs of the form
https://www.wikidata.org/entity/Q3807415.rdf are not canonical at all - we
support them for convenience, but they should not be used as identifiers, and
should not show up in our output anywhere.

You can see the changes I made to the documentation here:
https://www.wikidata.org/w/index.php?title=Wikidata%3AData_access&type=revision&diff=245768426&oldid=236886315

Sorry about the confusion.

-- daniel

Am 27.08.2015 um 09:20 schrieb Richard Light:

This described a postfix pattern which delivers RDF XML (e.g. [2]). However,
this pattern is itself subject to content negotiation, and an initial 303
response converts the URL to e.g. [3].  I am interested in knowing what pattern
of URL will deliver RDF/XML /without /requiring content negotiation, and the
answer to that question is not [2] but [3].  This matters, for example, in
scenarios where one wants to use XSLT's document() function to retrieve an RDF
XML response directly.  The URL pattern [2] will fail.  So the documentation is
currently unhelpful.

[...]

[1] https://www.wikidata.org/wiki/Wikidata:Data_access
[2] https://www.wikidata.org/entity/Q3807415.rdf
[3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf




--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Content negotiation

[Daniel Kinzler]

Hi Richard!

You are right, the Data access documentation did not properly distinguish
between concept URI and data URL. I have fixed this now. URLs of the form
https://www.wikidata.org/entity/Q3807415.rdf are not canonical at all - we
support them for convenience, but they should not be used as identifiers, and
should not show up in our output anywhere.

You can see the changes I made to the documentation here:
https://www.wikidata.org/w/index.php?title=Wikidata%3AData_access&type=revision&diff=245768426&oldid=236886315

Sorry about the confusion.

-- daniel

Am 27.08.2015 um 09:20 schrieb Richard Light:
> This described a postfix pattern which delivers RDF XML (e.g. [2]). However,
> this pattern is itself subject to content negotiation, and an initial 303
> response converts the URL to e.g. [3].  I am interested in knowing what 
> pattern
> of URL will deliver RDF/XML /without /requiring content negotiation, and the
> answer to that question is not [2] but [3].  This matters, for example, in
> scenarios where one wants to use XSLT's document() function to retrieve an RDF
> XML response directly.  The URL pattern [2] will fail.  So the documentation 
> is
> currently unhelpful.
[...]
> [1] https://www.wikidata.org/wiki/Wikidata:Data_access
> [2] https://www.wikidata.org/entity/Q3807415.rdf
> [3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikidata-tech] Question on bot flag in wbeditentity

[Markus Krötzsch]

On 26.08.2015 23:49, Daniel Kinzler wrote:

Am 26.08.2015 um 17:08 schrieb Markus Krötzsch:

Ok, but when a user edits a wiki thourgh the browser, this is not related to the
API anyway, is it?


It is. The UI uses the same API calls a bot would use.



Right, of course, but since my code is unlikely to be used as a Web UI 
backend (it's Java), this would not be a major reason for me to support 
the bot flag. But Revi's point is enough to convince me that I should 
support this nonetheless.


Markus



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

Re: [Wikidata-tech] Question on bot flag in wbeditentity

[Markus Krötzsch]

On 27.08.2015 00:51, Hong, Yongmin wrote:

Sometimes when community want to approve tasks for already flagged bot,
they want bot doesn't mark their task as bot edit so it appears on RC
and Watchlist as non-bot edit. I think this can be a reason?


Thanks. This is a relevant use case indeed! I will add support for the 
bot flag to my code then.


Markus





--
Revi
https://revi.me
-- Sent from Android --

2015. 8. 27. 오전 12:08에 "Markus Krötzsch"
mailto:mar...@semantic-mediawiki.org>>님
이 작성:

On 26.08.2015 12:27, Addshore wrote:

The reason our bot flag works like this is to remain consistent
with all
other mediawiki API modules.

See https://www.mediawiki.org/wiki/Manual:Bots#The_.22bot.22_flag
Mainly, Not all users with this right are "bots".


Ok, but when a user edits a wiki thourgh the browser, this is not
related to the API anyway, is it? I wonder in which cases a users
with a bot flag makes an edit through the API that should not be
flagged as "bot".

Background: I am currently implementing write access to Wikidata. I
am inclined to set the bot flag on all requests to simplify the
interface.

Cheers,

Markus


Cheers

Addshore

On 26 August 2015 at 10:51, Markus Krötzsch
mailto:mar...@semantic-mediawiki.org>
>>
wrote:

 Hi,

 I wondered why wbeditentity has a parameter "bot". The
documentation
 says that this will mark the edit as a bot edit, but only
if the
 user is in the bot group. In other words, users in the bot
group can
 use this parameter to decide if they want to have their
API-based
 edit flagged as bot or not. Is there any reason why a user
in bot
 group would *not* want their API-based edit flagged as bot?

 Cheers,

 Markus

 ___
 Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org

 >
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech




--
Addshore


___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org

https://lists.wikimedia.org/mailman/listinfo/wikidata-tech



___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org

https://lists.wikimedia.org/mailman/listinfo/wikidata-tech



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




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

Re: [Wikidata-tech] Content negotiation

[Richard Light]

Bene,

Thanks for this. Yes, that works.

For SELECT queries, the response format is 
application/sparql-results+xml by default (even without specifying the 
format parameter), and the only other format I could persuade it to 
offer was JSON (with format=json).


For CONSTRUCT queries (the useful sort :-) ), you need format=rdf (or 
format=application/rdf+xml), which returns a lovely RDF XML document.  
If you omit the format parameter, you get a 'File not found' error.


If you put format=json, you do get a JSON response, but (a) the file 
type isn't specified: the response filename is just the generic 
'sparql', and (b) the JSON that is returned looks a bit reified to me.  
Others can comment on whether this is what they would expect from 
serializing the results of a CONSTRUCT query in JSON. [1]


Richard

[1] 
http://wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql?query=prefix%20wdt:%20%3Chttp://www.wikidata.org/prop/direct/%3Eprefix%20wd:%20%3Chttp://www.wikidata.org/entity/%3E%20CONSTRUCT%20{?h%20wdt:P734%20?name%20.}%20WHERE%20{%20?h%20wdt:P31%20wd:Q5%20.?h%20wdt:P734%20?name%20.?name%20rdfs:label%20%22Light%22@en}%20LIMIT%20100&format=json


On 27/08/2015 08:24, Bene* wrote:

Hi Richard,

I can only answer the last part of your question but you can access 
the SPARQL endpoint directly under 
wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql?query= and I think 
you can also add a format parameter to specify in which format the 
result should be returned.


Best regards
Bene

Am 27.08.2015 um 09:20 schrieb Richard Light:


Hi,

I am doing some 'kicking the tyres' tests on Wikidata as Linked 
Data.  I like the SPARQL end-point, which is more helpful than most, 
and successfully managed a query for "people with the surname Light" 
last night.  (Only five of them in the world, apparently, but that's 
another matter. :-) )


What I do have an issue with is the content negotiation.  I kept 
failing to get an RDF rendition of my results, and as a last resort I 
read the documentation [1].


This described a postfix pattern which delivers RDF XML (e.g. [2]). 
However, this pattern is itself subject to content negotiation, and 
an initial 303 response converts the URL to e.g. [3].  I am 
interested in knowing what pattern of URL will deliver RDF/XML 
/without /requiring content negotiation, and the answer to that 
question is not [2] but [3].  This matters, for example, in scenarios 
where one wants to use XSLT's document() function to retrieve an RDF 
XML response directly. The URL pattern [2] will fail.  So the 
documentation is currently unhelpful.


In a similar vein, is there a syntax for running a SPARQL query on 
Wikidata such that the response is delivered as RDF XML?  In many 
end-points there is a parameter you can add to specify the response 
format, which allows you to submit searches as HTTP requests and 
include the results directly in your (in my case XML-based) 
processing chain.  An HTML results page isn't very machine-processible!


Thanks,

Richard

[1] https://www.wikidata.org/wiki/Wikidata:Data_access
[2] https://www.wikidata.org/entity/Q3807415.rdf
[3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf

--
*Richard Light*


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




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


--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Content negotiation

[Bene*]

Hi Richard,

I can only answer the last part of your question but you can access the 
SPARQL endpoint directly under 
wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql?query= and I think 
you can also add a format parameter to specify in which format the 
result should be returned.


Best regards
Bene

Am 27.08.2015 um 09:20 schrieb Richard Light:


Hi,

I am doing some 'kicking the tyres' tests on Wikidata as Linked Data.  
I like the SPARQL end-point, which is more helpful than most, and 
successfully managed a query for "people with the surname Light" last 
night.  (Only five of them in the world, apparently, but that's 
another matter. :-) )


What I do have an issue with is the content negotiation.  I kept 
failing to get an RDF rendition of my results, and as a last resort I 
read the documentation [1].


This described a postfix pattern which delivers RDF XML (e.g. [2]). 
However, this pattern is itself subject to content negotiation, and an 
initial 303 response converts the URL to e.g. [3].  I am interested in 
knowing what pattern of URL will deliver RDF/XML /without /requiring 
content negotiation, and the answer to that question is not [2] but 
[3].  This matters, for example, in scenarios where one wants to use 
XSLT's document() function to retrieve an RDF XML response directly.  
The URL pattern [2] will fail.  So the documentation is currently 
unhelpful.


In a similar vein, is there a syntax for running a SPARQL query on 
Wikidata such that the response is delivered as RDF XML?  In many 
end-points there is a parameter you can add to specify the response 
format, which allows you to submit searches as HTTP requests and 
include the results directly in your (in my case XML-based) processing 
chain.  An HTML results page isn't very machine-processible!


Thanks,

Richard

[1] https://www.wikidata.org/wiki/Wikidata:Data_access
[2] https://www.wikidata.org/entity/Q3807415.rdf
[3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf

--
*Richard Light*


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


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

[Wikidata-tech] Content negotiation

[Richard Light]

Hi,

I am doing some 'kicking the tyres' tests on Wikidata as Linked Data.  I 
like the SPARQL end-point, which is more helpful than most, and 
successfully managed a query for "people with the surname Light" last 
night.  (Only five of them in the world, apparently, but that's another 
matter. :-) )


What I do have an issue with is the content negotiation.  I kept failing 
to get an RDF rendition of my results, and as a last resort I read the 
documentation [1].


This described a postfix pattern which delivers RDF XML (e.g. [2]). 
However, this pattern is itself subject to content negotiation, and an 
initial 303 response converts the URL to e.g. [3].  I am interested in 
knowing what pattern of URL will deliver RDF/XML /without /requiring 
content negotiation, and the answer to that question is not [2] but 
[3].  This matters, for example, in scenarios where one wants to use 
XSLT's document() function to retrieve an RDF XML response directly.  
The URL pattern [2] will fail.  So the documentation is currently unhelpful.


In a similar vein, is there a syntax for running a SPARQL query on 
Wikidata such that the response is delivered as RDF XML?  In many 
end-points there is a parameter you can add to specify the response 
format, which allows you to submit searches as HTTP requests and include 
the results directly in your (in my case XML-based) processing chain.  
An HTML results page isn't very machine-processible!


Thanks,

Richard

[1] https://www.wikidata.org/wiki/Wikidata:Data_access
[2] https://www.wikidata.org/entity/Q3807415.rdf
[3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf

--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech