[Wikidata-tech] API JSON format for warnings
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=paraminfo&modules=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
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
Re: [Wikidata-tech] Content negotiation
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