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
Re: [Wikidata-tech] Write data with Wibase API 'wbeditentity'
Hi,
the issue that there is no meaningful error message is tracked in
https://phabricator.wikimedia.org/T93668
Best regards
Bene
Am 12.08.2015 um 11:26 schrieb Addshore:
Hi all.
So I was sent a link to the instance and had a quick look and it was
as I suspected.
(here is my response with links removed..)
The JSON includes the following:
P251: [
{
rank: normal,
mainsnak: {
snaktype: value,
property: P251,
datavalue: {
type: wikibase-entityid,
value: {
entity-type: item,
numeric-id: 85
}
},
datatype: wikibase-item
},
type: statement
}
],
Note that this is trying to use P251 as a 'wikibase-entityid'.
When looking at the property page
http://SOMEHOST/index.php/Property:P251 you can see that the datatype
is listed as 'String'.
It was said in a previous email that P251 should refer to another
item, in which case this property has been created incorrectly!
When creating a property, for example on
http://SOMEHOST/index.php/Special:NewProperty
you can see that there is a 'data type' field. This allows you to
select the type of data to be stored!
This is also available through the API
You'll have to create a new property to replace P251 that uses and
'Item' instead of 'String'
Addshore
On 11 August 2015 at 10:22, Addshore addshorew...@gmail.com
mailto:addshorew...@gmail.com wrote:
Hi Bo!
Would it be possible to get access / a URL to this test instance?
Feel free to send it to me outside of this list (if possible)
Addshore
On 11 August 2015 at 08:05, Bo Ferri z...@smiy.org
mailto:z...@smiy.org wrote:
Hi Addshore,
currently, I can't see what's wrong with the Statement with
the property P251. It should refer to another Item (which
should be possible within the Wikidata data model). This is
the difference between all other Statements - they simply
refer to literal Values. I also had a look at the JSON
serialisation documentation. In the Snak section [1] I can
find an example that looks similar to mine (or maybe I'm blind
and oversee something). Furthermore, I'm serialising POJO
objects from the Wikidata Toolkit (i.e. I do not construct the
JSON at my own). The Item that is the Value of this Statement
exists already in my Wikibase instance (all properties exists
as well).
We are running a nightly snapshot of MediaWiki (incl. Wikibase
extension).
Thanks a lot in advance for all your help.
Cheers,
Bo/T
[1] https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON#Snaks
Quoting Addshore addshorew...@gmail.com
mailto:addshorew...@gmail.com:
At a guess this is due to a miss match between the
datavalue of a property
and the datavalue that you are trying to set in a
statement for that
property.
The error also says that it gets an array where it expects
a string so I
guess the issue is with P251 where the value is an array
instead of a
string!
Could P251 possibly be a string?
On 10 August 2015 at 14:25, Bo Ferri z...@smiy.org
mailto:z...@smiy.org wrote:
Hi all,
(apologies, if this is not the right place for raising
the following issue
(if this is the case, then please delegate me to a
more appropriated place
;) ))
we are currently evaluating Wikibase as storage for
D:SWARM GDM data (see
[1,2]). Right now, we have a prototype client [3] that
makes use of a
Wikidata Toolkit fork [4]. So far, we were able to
write/create simple
items and properties. However, we also would like to
create new items with
a given set of statements. Therefore, we intended to
utilise the
'wbeditentity' HTTP API (and I had (and still have) a
lively conversation
with Markus Krötzsch about this topic, see [5]). We
get (a kind of) item
JSON serialisation (e.g. with help of
JacksonObjectFactory-based
DatamodelConverter (Wikidata Toolkit code)). However,
when sending this to
the 'webeditentity' API we always receive an error
response like this:
{
error: {
code: modification-failed,
info: array instead of string,
messages
Re: [Wikidata-tech] Change: including entrypoint now required for Wikibase
Hi Jan, thanks for working on a better extension registration of Wikibase. I've found one nitpick in your instruction. Am 16.06.2015 um 22:20 schrieb Jan Zerebecki: Your Wikibase installation will now require you to include its entrypoint. (No change needed for production.) If you didn't already have something like this in your LocalSettings.php you now need to: require_once $IP/extensions/Wikibase/Wikibase.php; Or alternatively: require_once $IP/extensions/Wikibase/repo/Wikibase.php; require_once $IP/extensions/Wikibase/client/Wikibase.php; The file Wikibase/client/Wikibase.php doesn't exist, it is Wikibase/client/WikibaseClient.php. Maybe we should rename WikibaseClient.php to Wikibase.php and leave a b/c alias to avoid confusion. Best regards Bene ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] Badges
Am 04.02.2014 12:21, schrieb Daniel Kinzler: Am 03.02.2014 20:37, schrieb Bene*: I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled? In that case, both badges would be shown. The idea is: if it IS wrong, it should LOOK wrong. Having both badges on the same page violates a convention. The convention should not be enforced by the software but by the community (possibly with the help of bots, common.js, etc). I would propose to add a css class for each badge that applies to a given language link. Per default, these classes would do nothing. Each client wiki can then define site CSS (or JS) to make some badges visible. Interesting, so in your opinion the actual display of items should happen via the common.css? I think this can work though I don't know if we should leave this implementation detail to the local wikis. At least, it would prevent another config to be added to the client which is very recommened from my side. Also the wiki could rank the badges easier. (New css properties override old ones.) Thus I support your idea leaving this to the client wikis. Another question, however, is which tooltip title should be added to the badges sitelink. We could use the description of the wikidata item but I am not sure if we can access it easily from client. However, it would provide an easy way to translate the tooltip without some hacky mediawiki messages. Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] Badges
Am 03.02.2014 22:32, schrieb Michał Łazowik: Hey, Wiadomość napisana przez Lydia Pintscher lydia.pintsc...@wikimedia.de w dniu 3 lut 2014, o godz. 20:44: On Mon, Feb 3, 2014 at 8:37 PM, Bene* benestar.wikime...@gmail.com wrote: Hi Lydia, I would be glad if you explained a bit further how this feature will work on client. There needs to be a mechanism to select which items are visible in the interwiki links section and which are not. This will perhaps be a setting on the client. However, even if we say, only FA and GA badges should be shown in the article, it can still come to collisions when a sitelink has two badges which are both specified in the client's config. How should this cases be handled? We could always show the first or last in the config. I'd go with only FA/GA for sidebar, the only config would be to indicate under which items on Wikidata they are. FA would be preferred over GA. Other badges would be accessible via Lua and it would be up to the communities how to use them. Or even just create some Lua module that would insert current templates used on Wikipedias based on data from Wikidata. Then no configuration on clients would be needed and transition would be seamless. Bene* suggested earlier that then communities could decide not to use Wikidata for badges, but actually they requested that feature. Also imposing decisions on them is not that nice. I don't know though what performance impact that might have. Regards, Michał Hey, I agree with everything said. Also having a rank of badges seems to be a good idea. However, I am not sure if Lua can handle the other badges because then a lua template would have to be inserted on *every* Wikipedia page. For the future, we must think about another mechanism so that badges like citation needed are added automatically, too. Maybe some lua scripts will be available on all pages by default? Best regards, Bene ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
[Wikidata-tech] Badges
Hi guys, I added a comment on bug 40810 but I also want to send it here to reach more people. We still need to discuss how the badges should work in general. At the development plan [1] it says Each sitelink can have zero or one badge attached to it. This does not match the current implementation which allows multiple badges. So the implementation needs to be changed to only supporting one badge. However, if we decide to keep the option of multiple badges we face some other problems. First, the ui gets harder to be implemented on Wikidata. This is not a real problem though. But a real problem is that we cannot determine which badge we want to display on the client. The only option I see to solve this issue is either to create another config variable (very ugly) or to only allow one badge as stated in the development plan anyway. Best regards, Bene* [1] https://www.wikidata.org/wiki/Wikidata:Development_plan ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] UI for site link badges
20.01.2014 19:19, David Cuenca: On Mon, Jan 20, 2014 at 6:13 PM, Lydia Pintscher lydia.pintsc...@wikimedia.de mailto:lydia.pintsc...@wikimedia.de wrote: * We should allow more than one badge per sitelink. * We can start with supporting just one badge per sitelink. I agree with your two points. Since badges don't need statements, just associated items to any given page, would it be possible to adapt the alias interface to tag sitelinks with badges? GUI-wise, is more or less what is needed to fulfill those requirements, a second row for each of the sitelinks that lists all the badges (actually items) associated with a given article in a language. If there the sitelink list grows too large, it could be hidden, with a 4th column Badges (next to Language-Code-Linked page) with a text X badges (expandable, similar to statement sources). Not sure if I expressed myself correctly or if it is feasible, I could draw a mockup if wanted. Hi, I am not sure if you got the point which I criticize. While with some effort we could create an interface on Wikidata supporting several badges [1] we are still facing a problem on the client. How should we choose the badges that should be visible on Wikipedia against those that aren't relevant in the in other languages section? I know, one answer is to add another config variable, but this is only a short solution because it will end up in adding another config and even one more so that we finally will have content in the code base. This is something we should really avoid. Also there exist some mockups already on Commons [1] [2]. [1] https://commons.wikimedia.org/w/index.php?title=File:Site_link_badges_edit_interface_%282%29.png [2] https://commons.wikimedia.org/w/index.php?title=File:Site_link_badges_edit_interface.png Best regards, Bene ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
[Wikidata-tech] UI for site link badges
Hi devs,
recently I had a discussion on IRC on how badges for site links should
work. After some time I realized that there is a general design issue
with their implementation.
The original idea of badges is to replace the FA/GA templates on
Wikipedias. This makes sense as it is centralized data which is used in
every Wikipedia. On Wikidata we can place that the article about XXX on
enwiki is a good/featured article and this will be shown on every
Wikipedia having a corresponding article. So basically, we are just
removing the {{Link GA|en}} or {{Link FA|en}} template and adding this
information to Wikidata. You can see that this is the last step away
from the old interwiki system.
However, there are proposals to badges that go far beyond this original
idea. Even the yet written implementation has such issues. As everybody
will easily understand, an article can be either ga or fa or none.
However, it cannot be ga *and* fa together. Thus one sitelink should
only be connected to a maximum of one badge. In contrast, the
implementation allows more than one badge, even worse, it allows an
infinite number of badges. Other proposals want badges to support
templates concerning meta information of the local article. However,
this information do really *not* concern other Wikipedias. Or can you
imagine a Wikipedia that wants to display a this article needs sources
icon next to the (probably not existing) fa icon? This example makes
clear that such meta information that has no value to another Wikipedia
than itself should not be stored on Wikidata, too. Wikidata is a place
for central data, not any data. For the Wikipedias' internal meta
information the working categories work really fine today and there is
no reason to force this system into Wikidata without any benefit to
Wikidata or the Wikipedias themselves.
So finally, my proposal is to only support one badge per sitelink. And
also to only support badges that make sense to have at a central point
and that will be used by more than one Wikipedia. I think this makes the
ui easier to understand and the code not relying on super-huge config
list showing all possible meta information that could be stored as
badges resulting in another huge statement system, but even worse.
Please keep this concerns in mind when deciding how the badges should work.
Best regards,
Bene*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] RFC: How to Implement Entity Redirects?
I have created a page on metawiki to document this discussion and make it more available: https://meta.wikimedia.org/wiki/Wikidata/Development/Entity_redirect_after_merge Best regards, Bene* Hello all! Once more, I'm taking a whack at implementing support for entity redirects - that is, we want Q1234 to become a redirect to Q2345 after we merged Q1234 into Q2345. My question is how to best model this. First off, a quick primer of the PHP classes involved: * We have the Entity base class, with Item and Property deriving from it, for modeling entities. * As glue for treating entities as MediaWiki page content, we have the EntityContent base class, and ItemContent and PropertyContent deriving from that (along with their handler/factory classes, EntityHandler, ItemHandler and PropertyHandler). Presently, each type of Entity is assigned a MediaWiki namespace, and all pages in that namespace have the corresponding content type. Now, there are various ways to model redirects. I have tried a few: 1) first I tried implementing redirects as a mode any Entity may have. The advantage is that redirects can seamlessly occur anywhere real entities can occur, e.g. in dumps, diffs, undo operations, etc. However, many operations that are defined on real entities are not defined on redirects (e.g. set label, etc), so we would end up with a lot if if redirect, do this, else, do that checks all over the code base. 2) second I tried implementing redirects as a mode any EntityContent may have, following the idea that redirects are really a MediaWiki concept, and should be implemented outside the Wikibase data model. This still requires a lot of if redirect, do this, else, do that checks, but only in places dealing with EntityContent, not all places dealing with Entities. 3) third I tried using a separate entity type for representing redirects: a RedirectContent points to an EntityContent, there is no mode, no need for extra checks, no chance for confusion. However, we break a few basic assumptions, most importantly the assumption that all pages in an entity namespace contain an EntityContent of the respective type. None of these solutions seem satisfactory for the indicated reasons, and also some additional consideration explained below. 4) This lead me to come fully cycle and consider another option: make redirects a special *type* of Entity, besides Item and Property. This would again allow straight forward diffs (and thus undo-operations) between the redirected and the previous, un-redirected version of a page; Also, it would not compromise code that operates on Item on Property objects. But since there are still many operations defined for Entity that make no sense for redirects, we would need to insert another class into the hierarchy (let's call it LabeledEntity) which would be a base class for Item and Property, but not for Redirect. This would require quite a bit of refactoring, and would introduce redirects as a first order citizen into the Wikibase data model. Which of the four options do you prefer? Or can you think of another, better, option? Below are some more points to consider when deciding on a design: In a addition to the OO design questions outlined above, one important question is how to handle redirects in the wb_entity_per_page table; that table contains a 1:1 mapping of entity_id - page_id. It is used, among other things, for listing all entities and for checking whether an entity exists. HOw should redirects be represented in that table? They could be: a) omitted (making it hard to list redirects), b) or use the redirect's page ID (maintaining the 1:1 nature, but pointing to a page that actually does not contain an entity), c) or use the target entities page ID (breaking the 1:1 nature of the table, but associating the ID with the accurate place). For b) and c), a new column would be needed to mark redirects as such. When deciding on how to represent redirects internally, we need to consider how they should be handled externally. Of course, when asking for an entity that got redirected, we should get the target entity's content, be it using the regular HTML page interface, the API, the linked data interface, etc. In RDF dumps, we would probably want redirects to show up as owl:sameAs relations (or something similar that allows one URI to be indicated as the primary one). Should redirects also be present in JSON dumps? If so, should it also be possible to retrieve the JSON representation of entities from the API, in places where usually real entities would be? -- daniel ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] Reusable serialization component
* Almost no code should know concrete instances of serializers. Program against the interfaces. Ie, when the constructor of a serializer for a higher level object (ie SnakSerializer) takes a collaborator for a lower level one (ie DataValueSerializer), type hint against the interface (ie Serializer $dataValueSerializer). Hmm, this causes some other design issues. We will have a SnakSerializer which has to take a $dataValueSerializer. Of course we should not specify a concrete type because of flexibility, but a problem of this solution is that wrong Serializers that cannot handle DataValues will only throw an exception at runtime but do not show a warning when compiling. Do you have any suggestions how we can avoid those issues? Best regrads, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] Reusable serialization component
Hi, Hmm, this causes some other design issues. We will have a SnakSerializer which has to take a $dataValueSerializer. Of course we should not specify a concrete type because of flexibility, but a problem of this solution is that wrong Serializers that cannot handle DataValues will only throw an exception at runtime but do not show a warning when compiling. Do you have any suggestions how we can avoid those issues? Good observation. This, a decrease in type safety, is a typical trade-off one makes when creating boundaries. This means the code constructing a SnakSerializer is responsible for making sure it is feeding in a Serializer implementation that can serialize data values. A small price to pay for the decoupling and flexibility gained. Ok, this sounds reasonable. Also note that not a lot of code should be constructing these service objects, and know about the dependencies. In fact, this likely should only be done in one place, which is a factory provided by the library. An example of this can be seen here: https://github.com/wmde/AskSerialization/blob/master/src/Ask/DeserializerFactory.php Thanks for the example. I think this will be the next step after we have finished the serializers and deserializers. Another important thing to realize is that if one writes the right component and integration tests, any incorrect wiring up of the serializes will be found. I see that if we write good tests all problems with types will be found at least when running the tests. This sounds very reasonable. Thank you for your explanations. :-) Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] RFC: How to Implement Entity Redirects?
Hi, Now, there are various ways to model redirects. I have tried a few: 1) first I tried implementing redirects as a mode any Entity may have. The advantage is that redirects can seamlessly occur anywhere real entities can occur, e.g. in dumps, diffs, undo operations, etc. However, many operations that are defined on real entities are not defined on redirects (e.g. set label, etc), so we would end up with a lot if if redirect, do this, else, do that checks all over the code base. I agree that this would bring lots of disadvantages to the current code base. 2) second I tried implementing redirects as a mode any EntityContent may have, following the idea that redirects are really a MediaWiki concept, and should be implemented outside the Wikibase data model. This still requires a lot of if redirect, do this, else, do that checks, but only in places dealing with EntityContent, not all places dealing with Entities. In my opinion this would work better and I prefer it to #1. However, I guess the data won't be available in dumps etc. 3) third I tried using a separate entity type for representing redirects: a RedirectContent points to an EntityContent, there is no mode, no need for extra checks, no chance for confusion. However, we break a few basic assumptions, most importantly the assumption that all pages in an entity namespace contain an EntityContent of the respective type. Agreed this isn't the best idea. None of these solutions seem satisfactory for the indicated reasons, and also some additional consideration explained below. 4) This lead me to come fully cycle and consider another option: make redirects a special *type* of Entity, besides Item and Property. This would again allow straight forward diffs (and thus undo-operations) between the redirected and the previous, un-redirected version of a page; Also, it would not compromise code that operates on Item on Property objects. But since there are still many operations defined for Entity that make no sense for redirects, we would need to insert another class into the hierarchy (let's call it LabeledEntity) which would be a base class for Item and Property, but not for Redirect. This would require quite a bit of refactoring, and would introduce redirects as a first order citizen into the Wikibase data model. Yes, this would require a bit lot of refactoring but it seems quite reasonable. I don't know if we should change the whole DataModel for this feature, but perhaps there is no solution that works better than this. The only one I can see is #2 but it has also some disadvantages. Which of the four options do you prefer? Or can you think of another, better, option? Below are some more points to consider when deciding on a design: In a addition to the OO design questions outlined above, one important question is how to handle redirects in the wb_entity_per_page table; that table contains a 1:1 mapping of entity_id - page_id. It is used, among other things, for listing all entities and for checking whether an entity exists. HOw should redirects be represented in that table? They could be: a) omitted (making it hard to list redirects), b) or use the redirect's page ID (maintaining the 1:1 nature, but pointing to a page that actually does not contain an entity), c) or use the target entities page ID (breaking the 1:1 nature of the table, but associating the ID with the accurate place). For b) and c), a new column would be needed to mark redirects as such. I would prefer b) as it does not break the idea of the table and makes also more sense if we consider handling redirects as entities. This are my first impressions of entity redirects. I prefer the options 2 and 4 but don't have a strong opinion. Maybe I will also think of another option later. Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] RFC: How to Implement Entity Redirects?
Hi guys, is there any progress on this topic? I am interested how you will decide to implement the redirect feature and maybe also contribute to it if you have decided on the current design questions. Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
[Wikidata-tech] New name for ApiWikibase class
Hi guys, the ApiWikibase class currently mainly supports the editing of single entities or getting claims etc, but still only for one single entity. Api modules like GetEntities do not really fit into this class. Also, there will be lots of Query Api modules in the future (see https://bugzilla.wikimedia.org/show_bug.cgi?id=55967) who need their own Api base class. Thus I propose to rename the current ApiWikibase class to something like ApiWikibaseSingle (I know the name is horrible but it shows what I mean) and create another class called ApiWikibaseQuery or sth like that for the query modules. Finally there could be a base class called ApiWikibase again that provides general functions like getVersion() or getHelpUrls(). Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] New name for ApiWikibase class
Hi, Also, there will be lots of Query Api modules in the future I'm not aware of this being on the roadmap. How did you figure this is the case? To be honest because I wanted to implement the queries because they are really needed for me and other bot operators. need their own Api base class. Since the MediaWiki API has several serious design issues, we seek to only have minimal binding to it. This means that we will not have business logic in our API modules themselves, and that there will be no need for sharing code via inheritance. (Note that sharing code via inheritance as done by the MW API is one of the design issues we want to avoid.) An example of a module implemented as we want to do in the future can be seen here: https://github.com/wikimedia/mediawiki-extensions-WikibaseQuery/blob/master/src/Wikibase/Query/Api/EntitiesByPropertyValue.php So the naming problem in question ought to not actually occur. But I think it would be evil if even the page to query items without interwikilinks would inherit from the ApiWikibase class because it provides functions like addSiteLinksToResult, addAliasesToResult or worse also attemptSaveEntity which really have nothing to do with quering data. If you see this functions you have to realize that the ApiWikibase class is only designed for api modules that edit or get data from one *single* entity. A module that queries data from *lots of* entities should not be a subclass of this class but however it would be a ApiWikibase module. This is the reason why the module should be renamed in my opinion. Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] New name for ApiWikibase class
In addition: An example of a module implemented as we want to do in the future can be seen here: https://github.com/wikimedia/mediawiki-extensions-WikibaseQuery/blob/master/src/Wikibase/Query/Api/EntitiesByPropertyValue.php As you can see, there is a @todo at getHelpUrls() . This is a function that could be inherited by a base class as well as getVersion() Best regards, Bene* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
