[Wikidata-tech] API JSON format for warnings

[Markus Krötzsch]

Hi,

I am wondering how errors and warnings are reported through the API, and 
which errors and warnings are possible. There is some documentation on 
Wikidata errors [1], but I could not find documentation on how the 
warning messages are communicated in JSON. I have seen structures like this:


{ warnings :
  {wbeditentity:
{messages:
   [{name:wikibase-self-conflict-patched,
 parameters:[],
 html: { *:Your edit was patched into the latest version, 
overriding some of your own intermediate changes.}

   }]
}
  }
}

I don't know how to provoke more warnings, or multiple warnings in one 
request, so I found it hard to guess how this pattern generalises. Some 
questions:


* What is the purpose of the map with the * key? Which other keys but 
* could this map have?
* The key wbeditentity points to a list. Is this supposed to encode 
multiple warnings of this type?
* I guess the name is a message name, and parameters are message 
arguments (as they are called in action=query) for the message?
* Is this the JSON pattern used in all warnings or can there also be 
other responses from wbeditentity?
* Is this the JSON pattern used for warnings in all Wikibase actions or 
can there also be other responses from other actions?

* Is there a list of relevant warning codes anywhere?
* Is there a list of relevant error codes anywhere? The docs in [1] 
point to paraminfo (e.g., 
http://www.wikidata.org/w/api.php?action=paraminfomodules=wbeditentity) 
but there are no errors mentioned there.


Thanks,

Markus

[1] https://www.mediawiki.org/wiki/Wikibase/API#Errors

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

Re: [Wikidata-tech] Content negotiation

[Bene*]

Hey,

maybe fixing this tasks would help new users to create their own SPARQL 
queries: https://phabricator.wikimedia.org/T101693


Best regards
Bene

Am 28.08.2015 um 10:45 schrieb Richard Light:



On 27/08/2015 23:37, Stas Malyshev wrote:

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.
I think help with query building is at least as important as 
serialization of results.  If you can't work out how to find anything, 
there will be no results to serialize. :-) Every SPARQL end-point 
exposes differently-structured RDF, so the first job a newcomer has is 
to try to work out what classes and properties are in there, and how 
they relate to each other.


So it would be good to have a guided query builder, which starts off 
I want to find ... with a drop-down list of classes (possibly 
complete, possibly a selection of the 'key' ones).  You select a 
class, and a second line pops up with a list of properties for that 
class.  Select one, and you get a text box with autocomplete to type a 
value into, etc.  So the query builder is itself using SPARQL queries 
to provide context-relevant options for the searcher.  When they have 
the result they want, the system can give them the SPARQL query which 
generated their result, for future reference and/or hand-editing.  But 
they don't actually /have /to write any SPARQL themselves.


Richard
--
*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