The folks of the Wikidata.lib project at the Hasso Plattner Institut have developed an extension to Wikibase that allows us to suggest properties to add to items, based on the properties already present (a very cool project, btw).
This is, conceptually, and extension to the Wikibase extension. This raises problems for managing dependencies:
* conceptually, the extension (property suggester) depends *on* wikibase. * practically, we want to install the property suggester as an optional dependency (feature/plugin/extension) *of* wikibase.
So, how do we best express this? How can composer handle this?
I think the most obvious/important thing to do is to have a separate module for the interface wikibase exposes to plugins/extensions. This would include the interfaces of the service objects, and some factory/registry classes for accessing these.
What's the best practice for exposing such a set of interfaces? How is this best expressed in terms of composer manifests? What are the next steps to resolve the circular/inverse dependencies we currently have?
-- daniel
PS: Below is an email in which Moritz Finke listed the dependencies the property suggester currently has:
-------- Original-Nachricht -------- Betreff: PropertySuggester Dependencies Datum: Thu, 6 Mar 2014 11:07:56 +0000 Von: Finke, Moritz Moritz.Finke@student.hpi.uni-potsdam.de An: Daniel Kinzler daniel.kinzler@wikimedia.de
Hi,
unten sind die Abhängigkeiten des PropertySuggesters nach Klassen sortiert...
Grüße Moritz
Abhängigkeiten PropertySuggester:
GetSuggestions:
use Wikibase\DataModel\Entity\ItemId; use Wikibase\DataModel\Entity\Property; use Wikibase\DataModel\Entity\PropertyId; use Wikibase\EntityLookup; use Wikibase\Repo\WikibaseRepo; use Wikibase\StoreFactory; use Wikibase\Utils;
use ApiBase; use ApiMain; use DerivativeRequest;
WikibaseRepo::getDefaultInstance()->getEntityContentFactory(); StoreFactory::getStore( 'sqlstore' )->getEntityLookup(); StoreFactory::getStore()->getTermIndex()->getTermsOfEntities( $ids, 'property', $language ); Utils::getLanguageCodes() 'type' => Property::ENTITY_TYPE )
SuggesterEngine:
use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Entity\PropertyId;
Suggestion:
use Wikibase\DataModel\Entity\PropertyId;
SimplePHPSuggester:
use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Entity\PropertyId;
use DatabaseBase; use InvalidArgumentException;
GetSuggestionsTest:
use Wikibase\Test\Api\WikibaseApiTestCase;
SimplePHPSuggesterTest:
use Wikibase\DataModel\Entity\PropertyId; use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Claim\Statement; use Wikibase\DataModel\Snak\PropertySomeValueSnak;
use DatabaseBase; use MediaWikiTestCase;
JavaScript:
wikibase.entityselector wbEntityId
I have discussed the dependency issue with Jeroen, so here is what I took away from the conversation:
* factoring the service interfaces out of the Wikibase extension would be nice to have, but is not necessary to resolve the present issue.
* An extension/plugin (in this case, the property suggester) will indeed typically have a dependency on the application/framework it was written for (in this case, wikibase).
* When installing a plugin stand-alone, the application (here: wikibase) would be installed somewhere in the vendor directory. This is fine for runnign unit tests against the plugin (the property suggester), but of course doesn't make much sense when we want to use wikibase and the suggester as mediawiki extensions (especially not if MediaWiki itself was pulled in as a dependency).
* In order to install extensions for an application in a way that the extensions are installed "under" the application, even though they depend on the app, and not vice versa, a "local build" can be used:
* We would create a composer manifest that defines the app (wikibase) and the extensions (the suggester, etc) as dependencies, and then use composer to install that. This will cause wikibase and the suggester to be installed "together", side by side, rather than putting wikibase "under" the suggester.
* In fact, we already do something like this with the "Wikidata" extension, which is just a build of Wikibase with all the dependencies and additions we want.
HTH -- daniel
Am 06.03.2014 16:03, schrieb Daniel Kinzler:
The folks of the Wikidata.lib project at the Hasso Plattner Institut have developed an extension to Wikibase that allows us to suggest properties to add to items, based on the properties already present (a very cool project, btw).
This is, conceptually, and extension to the Wikibase extension. This raises problems for managing dependencies:
- conceptually, the extension (property suggester) depends *on* wikibase.
- practically, we want to install the property suggester as an optional
dependency (feature/plugin/extension) *of* wikibase.
So, how do we best express this? How can composer handle this?
I think the most obvious/important thing to do is to have a separate module for the interface wikibase exposes to plugins/extensions. This would include the interfaces of the service objects, and some factory/registry classes for accessing these.
What's the best practice for exposing such a set of interfaces? How is this best expressed in terms of composer manifests? What are the next steps to resolve the circular/inverse dependencies we currently have?
-- daniel
PS: Below is an email in which Moritz Finke listed the dependencies the property suggester currently has:
-------- Original-Nachricht -------- Betreff: PropertySuggester Dependencies Datum: Thu, 6 Mar 2014 11:07:56 +0000 Von: Finke, Moritz Moritz.Finke@student.hpi.uni-potsdam.de An: Daniel Kinzler daniel.kinzler@wikimedia.de
Hi,
unten sind die Abhängigkeiten des PropertySuggesters nach Klassen sortiert...
Grüße Moritz
Abhängigkeiten PropertySuggester:
GetSuggestions:
use Wikibase\DataModel\Entity\ItemId; use Wikibase\DataModel\Entity\Property; use Wikibase\DataModel\Entity\PropertyId; use Wikibase\EntityLookup; use Wikibase\Repo\WikibaseRepo; use Wikibase\StoreFactory; use Wikibase\Utils;
use ApiBase; use ApiMain; use DerivativeRequest;
WikibaseRepo::getDefaultInstance()->getEntityContentFactory(); StoreFactory::getStore( 'sqlstore' )->getEntityLookup(); StoreFactory::getStore()->getTermIndex()->getTermsOfEntities( $ids, 'property', $language ); Utils::getLanguageCodes() 'type' => Property::ENTITY_TYPE )
SuggesterEngine:
use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Entity\PropertyId;
Suggestion:
use Wikibase\DataModel\Entity\PropertyId;
SimplePHPSuggester:
use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Entity\PropertyId;
use DatabaseBase; use InvalidArgumentException;
GetSuggestionsTest:
use Wikibase\Test\Api\WikibaseApiTestCase;
SimplePHPSuggesterTest:
use Wikibase\DataModel\Entity\PropertyId; use Wikibase\DataModel\Entity\Item; use Wikibase\DataModel\Claim\Statement; use Wikibase\DataModel\Snak\PropertySomeValueSnak;
use DatabaseBase; use MediaWikiTestCase;
JavaScript:
wikibase.entityselector wbEntityId
wikidata-tech@lists.wikimedia.org