On Fri, Mar 7, 2014 at 6:37 PM, Denny Vrandečić <vrandecic@gmail.com> wrote:

I still disagree - let me explain why. I think that trying to express a query definition into a single statement is very hard. Having a specific Query namespace allows us to create a completely new UI for them, allows us to use a different data model for Queries than for items, and allows us to treat Query pages very different (e.g. for caching) than, e.g. item pages.

Maybe I'm wrong, but "to create a completely new UI for [queries]" in my head translates as "more barriers for users to understand and navigate Wikidata".

The query doesn't need to be a single statement, but a single property for queries (I called it "same as query" but it could be named differently). You should be able to combine two statements of such property, or more, to create a complex query. What I think it also matters is to reuse the concepts the users are familiar with as much as possible.

For example, the different data model would allow us to restrict the number of queries on a page. If they were just a statement, what would stop a contributor from creating several such statements on one page?

On the mockup I intended to represent that the property "same as query" can have several statements, but they combine into a single query.

What happens when someone removes the "same as query" statement?

Same as now happens with other statements transcluded into wikipedia pages, when somebody notices the deletion, it gets restored.

What happens if someone adds it to the page for USA (e.g. "same as query" "instance of"->"country", "continent"->"North America", "population"->>300M)?

It will get corrected, it is a wiki, right? :)

Would this page suddenly be treated differently?

Not necessarily.

Also, you already show in your mock up that the "same as query" statement requires plenty of special code (e.g. for the different visualizations, etc.)

Same requirements as having queries as independent pages.

One option would be to have them as item pages, but then treat them continuously different. This would mean more and more exceptions and special casing in the code. I think that Queries and Items are sufficiently different to deserve their own treatment. In my personal opinion, this is provides sufficient reasons for Query pages and Item pages being distinct.

No need for different treatment, or exceptions. Just a property that acts as a query descriptor with as many modifiers as needed.

What would be the advantage of having Queries being expressed in the Items? Less entities?

Yes!

Less confusion about what these "list of"- and "category"-items mean?

Yes!

Both reasons I don't find sufficiently enticing to change my opinion on this.

And better navigation, and more simplicity to create a query, and no need of creating artificial divisions between pages that represent the same concept...

Cheers,

Micru