Hey,

Did you ever reply to my July 10 email asking for an explanation of

the distinct roles of the extensions you'd like to break out of DataValues?

Not directly. I've gone ahead an written a completely up-to-date overview of the current structure and how we plan to change it. See "DataValues and related components reorganization" send to wikidata-tech.

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

Hi,

for Semantic MediaWiki we had this already listed for a while here: < https://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata%3E The list is not completely up-to-date, it reflects the previous package structure.

Jeroen and I are trying to give a more comprehensive listing here:

1. DataValues Dependencies: * None Planned or already used by: * DataValues interfaces * simple PHP Bots processing Wikidata data (most likely through the Wikibase Data Model) * Inside Semantic MediaWiki as a replacement for the DataItem * Ask * Wikibase Data Model * DataValues interfaces Note: In general, DataValues is helpful for simply handling DataValues without having to work with them a lot. It is an extremely light weight container for a data value.

2. DataValues interfaces Dependencies: * DataValues Planned or already used by: * DataTypes * DataValues Implementations * ParamProcessor (formerly Validator). ParamProcessor in turn is used by ** Maps ** SubPageList ** Parser Fun Note: DataValues interfaces add the functionality to parse, format, and validate data values, i.e. services on top of DataValues if further functionality is required.

3. DataValues implementations Dependencies: * DataValues interfaces Planned or already used by: * Semantic MediaWiki * Semantic Maps * Semantic Result Formats * Wikibase client * Wikibase repo Note: These include more complex implementations of DataValues like Time and Coordinates, which are not used in simpler systems.

4. DataTypes Dependencies: * DataValues interfaces Planned or already used by: * more complex PHP bots using Wikidata data * Wikibase client * Wikibase repo * ValueView Note: Allows to define data types, i.e. containers for data values with certain constraints and specific implementations.

5. ValueView Dependencies: * DataTypes * jQuery Planned or already used by: * Wikibase repo * external websites Note: jQuery widgets to display and manipulate values of DataTypes.

I hope that explains the reorganization of DataValues and the related libraries, and that we can now move swiftly towards implementing this.

Cheers, Denny

Hi Rob,

responses inline.

2013/8/26 Rob Lanphier robla@wikimedia.org

On Fri, Aug 23, 2013 at 8:03 AM, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:

...

for Semantic MediaWiki we had this already listed for a while here: https://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata The list is not completely up-to-date, it reflects the previous package structure.

It would be helpful if there was a wiki page that reflected the current state of things. For MediaWiki core, we're trying to get into the practice of having RFCs for changes of this magnitude, and something of that level of rigor would be nice here too.

The current state is described here: http://www.mediawiki.org/wiki/Wikibase , more specifically here: < http://www.mediawiki.org/wiki/Wikibase#Packages_and_code_structure%3E

The new structure was described in Emails on Wikidata-tech, most recently here: < http://www.mail-archive.com/wikidata-tech@lists.wikimedia.org/msg00200.html%...

We are indeed not yet using the RFC process, but I would prefer if we could agree to move to this process in the future, as this particular discussion is going on already a bit longer than what I would expect for a discussion regarding the question about how to organize code.

1. DataValues

...

Note: In general, DataValues is helpful for simply handling DataValues without having to work with them a lot. It is an extremely light weight container for a data value.

It would be nice to have a less recursive explanation. :-) As near as I can see skimming the code, this is mainly validation code for data types that not native to PHP (e.g. LatLong, Time), and wrappers for ones that are native to PHP (e.g string), providing a consistent interface to all of them (e.g. getType, getSortKey, getArrayValue, toArray). Is that it in a nutshell?

I agree that the explanation sounds a bit recursive, this is a "feature" stemming in the fact that the packages is called DataValues and we (or maybe it is just me) in general lack a really good non-recursive terminology for these things. Improvements on the terminological issues are more than welcome.

Regarding your question: yes, it provides a consistent interface to such kind of data values (not types) and their common super class so that different code can deal generically with them. Note that some particular data values (in particular Coordinates and Time) would be moved to DataValues Implementation.

2. DataValues interfaces

Is this the code that's currently in ValueValidators?

And ValueParsers and ValueFormatters, for the simple DataValues.

3. DataValues implementations

Is this basically an expanded set of DataValues interfaces, base DataValues, or something else?

It adds more complex data values, like coordinates and time, that are not used in most cases, especially for the ParamProcessor, who e.g. should not depend on the highly complex time parser,.

I'll respond more on the other bits later, but I wanted to make sure I at least got this response out now.

Rob

I hope that helps, Denny

Hi Rob,

yes, that was also the answer we had to the previous thread on a very related topic:

http://www.gossamer-threads.com/lists/wiki/wikitech/375632

Once we have consensus on how to handle this kind of dependencies, code reuse, and code separation, we can revisit the structure. I would indeed be very happy if this would no longer block the changes on DataValues and DataTypes and the separation between the DataValue Implementations, etc., as they have been going on for months and are blocking the release for a number of extensions right now.

So, yes, I full agree - let us not further block for this change. Let us have the time to have the discussion properly. And then let's implement that consensus.

Cheers, Denny

2013/8/26 Rob Lanphier robla@wikimedia.org

Hi Denny,

I'll reply inline to your email later (probably under a different subject), but I should make one thing I personally don't think it's necessary for us to complete our conversation clarifying what the extensions are before we approve DataTypes. At this point, I doubt we're going to get you to change your mind about the architecture change, and so if you all can agree that we can revisit this change after we've had a complete discussion, and that we'll have a full conversation about the change, we can approve and deploy the changes you've made so far (assuming someone with +2 looks at the patch and agrees that it won't break anything). Sound reasonable?

Rob