Hi,
Two quick questions about orderings of stuff in JSON. Currently, we have
two order-related keys:
snaks-order
qualifiers-order
They are used to specify the order of groups of snaks in references
(snaks-order) and statements (qualifiers-order). This is needed since
the snak groups are stored in JSON maps in both cases (property => snak
list), and maps do not have order semantics.
Question 1: Why don't we also have some information about
statement/claim order? This seems to be necessary for using the API JSON
internally as planned.
Question 2: Wouldn't it be more convenient to store lists of things in
all cases, and have the "map" version just as an optional API switch for
users who don't care about order (it could remain the default)? This
would help to retrieve order information more easily.
Cheers,
Markus
Hi all. I'm writing to get input on a conceptual issue regarding the resolution
of redirects.
I'm currently in the process of implementing redirects for Wikibase Items
(bugzilla 66067). My present task is to add support for redirect resolution to
the EntityLookup service interface (and possibly the related
EntityRevisionLookup service interface; bugzilla 66075).
Currently, the two interfaces in question look like this (with some irrelevant
stuff omitted):
interface EntityLookup {
public function getEntity( EntityId $entityId, $revision = 0 );
public function hasEntity( EntityId $entityId );
}
interface EntityRevisionLookup extends EntityLookup {
public function getEntityRevision( EntityId $entityId, $revisionId = 0 );
public function getLatestRevisionId( EntityId $entityId );
}
Note that getEntityRevision returns an EntityRevision object (an Entity with
some revision meta data), while getEntity just returns an Entity object.
Also note that the $revision parameter in EntityLookup::getEntity is deprecated
and being removed (see patch Iafdcb5b38), while $revision in
EntityRevisionLookup::getEntityRevision is supposed to stay.
Presently, the attempt to look up an Entity via an ID that has been turned into
a redirect will result in an exception being thrown. To implement redirect
resolution, original intention was to leave the EntityRevisionLookup as is, and
change EntityLookup like this:
interface EntityLookup {
public function getEntity( EntityId $entityId, $resolveRedirects = 1 );
public function hasEntity( EntityId $entityId, $resolveRedirects = 1 );
}
...with the $resolveRedirects parameter indicating how many levels of redirects
should be resolved before giving up.
This gives use a convenient way to get the current revision of an entity,
following redirects; And it keeps the interface for requesting a specific, or
the latest, version of an Entity, with meta info attached.
However, it means we have to implement the logic for redirect resolution in
every implementation class, generally using the same code over and over (there
are currently three implementations of EntityRevisionLookup: the actual lookup,
a caching wrapper, and an in-memory fake).
Also, it does not give us a straight-forward way to get the meta-data of the
current revision while following redirects. For that, we'd have to modify
EntityRevisionLookup::getEntityReevision:
public function getEntityRevision(
EntityId $entityId,
$revisionId = 0,
$resolveRedirects = 0
);
This is ugly, and annoying since we'll want to *either* resolve redirects *or*
specify a revision. We could use a special value for $revisionId to indicate
that we not only want the current revision (indicated by 0), but also want to
have redirects resolved (indicated by "follow" or -1 or whatever):
public function getEntityRevision(
EntityId $entityId,
$revisionIdOrRedirects = 0,
);
That's concise, but somewhat magical. Or we could add another method:
public function getEntityRevisionAfterFollowingAnyRedirects(
EntityId $entityId,
$resolveRedirects = 1,
);
That's not quite obvious, and the awkward name indicates that this isn't really
what we want either.
Perhaps we can get around all this mess by making redirect resolution something
the interface doesn't know about? An implementation detail? The logic for
resolving redirects could be implemented in a Proxy/Wrapper that would implement
EntityRevisionLookup (and thus also EntityLookup). The logic would have to be
implemented only once, in one implementation class, that could be wrapped around
any other implementation.
>From the implementation's point of view, this is a lot more elegant, and removes
all the issues of how to fit the flag for redirect resolution into the method
signatures.
However, this means that the caller does not have control over whether redirects
are resolved or not. It would then be the responsibility of bootstrap code to
provide an instances that does, or doesn't, do redirect resolution to the
appropriate places. That's impractical, since the decisions whether redirects
should be resolved may be dynamic (e.g. depend on a parameter in an web API
call), or the caller may wish to handle redirects explicitly, by first looking
up without redirect, and then with redirect resolution, after some special
treatment.
So, it seems that the "ugly" variant with an extra parameter in
getEntityRevision() is the most practical, even though it's not the most elegant
from an OO design perspective.
What's your take on this? Got any better ideas?
-- daniel
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Hi Bene*,
thanks for your effort so far.
First of all, https://commons.wikimedia.org/wiki/Category:Wikidata_storyboards_-_Badges
is pretty outdated since, as you noted, it does not reflect managing
multiple badges.
However, I am not sure whether using an adaption of the aliases tool
is the most suitable method for adding badges. How about a list of all
badges being able to tick badges on/off by clicking? Having to trigger
a search for badges seems a bit over the edge. Instead of a
"placeholder" badge symbol, all "activated" badges would be displayed
next to each other.
Adding the HTML of the "badge selector" "anchor" right into the static
table seems reasonable since the the badge(s) should be displayed
without JavaScript as well while not having to maintain two different
implementations.
The "badge selector" should be a jQuery widget of its own. That would
allow having all the functionality and css in the widget's scope
without pasting specific styles in wikibase.css. In addition, the
"badge selector" would be independent as much as possible from the
legacy code of PropertyEditTool and EditableValue derivatives.
Rank selector and snak type selector may be an orientation on how to
proceed. Similar to those, you may use a single pop-up box as well -
you just need to adjust the content / activation state of the badges
according to the corresponding site link. Toggling would be managed by
the widget as well. You will need a mechanism (probably an event) to
notify the SitelinkEditTool when the status of a site link's badges
has changed - most of the logic should actually be pretty similar to
the rank selector.
Regarding the triangle: You could try putting the pop-up contents into
a jQuery.wikibase.wbtooltip or directly into a jQuery.Tipsy instance.
Hello,
I found, when looking at the external Json, that it uses different
notations for pretty much the same thing. If we talk about item ids on
the document level the Json hast the form:
"id":"Q1",
"type":"item"
Once you talk about item ids on the level of a snaks value it is:
"entity-type":"item",
"numeric-id":"1"
Is there any deeper meaning that prevents, using only one of these forms?
(Also notice, that "entity-type" is redundant, since it is already given
by a snaks "datatype":"wikibase-item")
Sincerly,
Fredo Erxleben
Hey Steffen and Andy,
Continuing what I started on Twitter here, as some more characters might be
helpful :)
It seems that both our projects (FLOW3 and Wikidata) are in a similar
situation. We are using Gerrit as CR tool, and TravisCI to run our tests.
And we both want to have Travis run tests for all patchsets submitted to
Gerrit, and then +1 or -1 on verified based on the build passing or
failing. To what extend have you gotten such a thing to work on your
project? Is there code available anywhere? If both projects can use the
same code for this, I'd be happy to contribute to what you already have.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
If you use puppet on a labs instance and are wondering where puppetd went...
puppet has been upgraded on labs to puppet 3.
If you use puppet on a labs instance, instead of doing "puppetd -tv" now it
is "puppet agent -tv".
Cheers,
Katie
--
Katie Filbert
Wikidata Developer
Wikimedia Germany e.V. | Tempelhofer Ufer 23-24, 10963 Berlin
Phone (030) 219 158 26-0
http://wikimedia.de
Wikimedia Germany - Society for the Promotion of free knowledge eV Entered
in the register of Amtsgericht Berlin-Charlottenburg under the number 23
855 as recognized as charitable by the Inland Revenue for corporations I
Berlin, tax number 27/681/51985.
Hi developers,
I am currently working on the user interface on Wikibase's repository to
edit badges. There exist several mockups [1] - especially [2] - but I
got stuck while trying to implement them actually. The resource system
of Wikibase is quite confusing and I am not sure if the way I tried it
[3] does really make sense and is the right attempt. Here are some
questions which came in my mind until now but I am sure there will be
more questions later. However, I would be glad if you can help me
already now to show me the right way.
First, I am not sure if the current attempt to add the HTML for the ui
into the sitelink's row is useful. I saw that most of those popup bubble
boxes are implemented as jquery widgets and added to the end of the
document. However, this might become a bit too hard because while the
options for a statement's rank are always the same but the badges are
different for each sitelink. So perhaps it is better how I implemented
it right now with the HTML hidden by default and positioned with
position:absolute.
Another question is if we should implement the toggling of the bubble
with plain CSS or by the use of javascript. In my opinion it is saner to
do this with javascript and will create a better look and feel. However,
I have no clue where the toggling logic should be put, so if this is a
widget or comes to the edit tool.
One issue concerns the arrow/triangle of the box pointing to the star.
Should this triangle created by a background image or by pure CSS?
All those questions are perhaps only the beginning but I'm sure we will
have a great badges edit tool once this is finished.
Best regards,
Bene*
[1]
https://commons.wikimedia.org/wiki/Category:Wikidata_storyboards_-_Badges
[2]
https://commons.wikimedia.org/wiki/File:Site_link_badges_edit_interface_%28…
[3] https://gerrit.wikimedia.org/r/#/c/124391/
Hey,
The upcoming 1.0 version of DataModel makes a breaking change to the
setLabel, setDescription and setAliasGroup methods of Fingerprint [0]. This
means that for now it is best to refrain from using these convenience
methods, as it makes migration to 1.0 harder.
[0] https://github.com/wmde/WikibaseDataModel/blob/master/RELEASE-NOTES.md
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
Hey,
Constructing entities from their serialization in tests has long been
discouraged. A few weeks back we removed support for this on the master
branch of DataModel. In going though the remaining occurrences, I find
myself surprised that some got introduced as little as two weeks ago, and
merged in by a member of the Wikidata team.
What to not do:
$item = new Item( array(
....
) );
What to do instead (as has been done in most places for quite some time):
$item = Item::newEmpty();
$item->setStuff();
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
.png){kind=link}