q="don't escape the backslash" :)

So you think it's not possible to link some of the queries to specific users?

Clearly we disagree on the proposed release, its scope and users expectations for privacy. If one thinks it's normal to publish users search history, the arguments you advance are probably a valid point of view.

Maybe page properties should include counts of lemmas, forms and senses, as they do for statements and identifiers.

Do we have any discussion of this usecase onwiki? It seems contrary to a problem raised onwiki.

Interesting point.

Thanks. I can get it to load know. Not sure what happened. I will have a look.

Thanks. I added details there as well.

I had a look at the sample, but there doesn't seem to be any data. The three compressed files seem empty.

(tries to imitate Lydia's voice) "it is fine"

You mean (e.g.) "visualize" and "visualise" on https://www.wikidata.org/wiki/Lexeme:L11 ?

To restrict search to properties, one can use "p:". Is it already planned somewhere to use "l:" for lexemes?

In recent days, I noticed it for newly created items as well

Noticed that as well.

How about doing this in the other direction: T85444#4271029

Shouldn't users opt-in to this?

When using https://query.wikidata.org/sparql in a browser, it displays an XML with some information about the database.

Couldn't be set as prefix or variable?

Thanks for looking into this.

It seems that even when using URI, the same service can be called just once.

Coming to the second part:

In T196798#4269194, @Lucas_Werkmeister_WMDE wrote:

Using a variable as the service endpoint is syntactically invalid,

Special:NewLexeme should also include a way to add a sense directly

Probably not. If the "Gloss" was added by a vandal I suppose this couldn't have happened without a "Sense" that should also be deleted.

If it's a problem having both formats, I think the input format only should be exported.

<quote>Acceptance Criteria:
"I can not remove the last Gloss of a Sense" </quote>

@Amire80 what's langcom's view on these?

Moving it to search wont solve it then.

I don't see clear disadvantages of doing the indexing Multichill suggests.

In terms of functionalities, what's the outcome of this?

I think it would help to not wait too long before fixing this.

It might be useful as a Wikibase feature, but on Wikidata itself it might not fully scale anymore.

Do we still need this?

I'd rank primarily by P31/P279 .. otherwise everything is assimilated to a PubMed item

It needs a cleanup of data in there as well.

Sounds like an interesting idea. It might be easier to do a static set and measure how that evolves. Uses can change a lot through changes in templates.

On Wikidata Query Server. Currently xds:integer(?v) is needed on quantities

Don't hold your breath ..

Could the output include an integer triple as well?

Should we display https://www.wikidata.org/wiki/MediaWiki:Wbqc-violation-message-single-value

In T173594#4123057, @Lucas_Werkmeister_WMDE wrote:

Does anyone disagree with any of those answers? :)

at some point "unique" was changed to "distinct" on Wikidata constraints.

I'm not sure if it's a good idea to allow any convertible unit by default.

what part is missing?

yeah .. probably the same thing. Hadn't notice that I unfocused it though.

At Wikidata, I tried to change or add value to statements with item datatype, e.g. enter the place of birth a person. The border around the entry field changes colors (depending on whether the value meets constraints or not), but then fails to allow me to save it (cancel or remove are enabled).

@BBlack can you confirm this is unrelated. @matej_suchanek had suggested T175473.