daniel added a comment. > For properties:
> > - ( language + label ): Labels act as identifiers, because properties are > usually shown with their label and nothing else (no id, no description) in > property-value pairs. > - ( language + alias ): I wonder where this comes from. Aliases are unique > per entity, but different properties can have the same aliases. This is still > useful in search results and suggesters, given they show perfect matches > first. No, different properties should //never// have the same alias. In Wikitext (parser function, Lua), properties can be //addressed// by their alias, so the alias must act as an identifier, and be unique. I'm not sure we are actually enforcing this right now, but conceptually, this constraint exists. However, like most of the constraints we impose, this is not absolutely guaranteed. Violations could for instance be introduced through import of property definitions (which is one reason imports are disabled per default). > For items: > > - ( language + label + description ): This reflects what we learned from > Wikipedia. Concepts with the same label exist (e.g. > http://en.wikipedia.org/wiki/Albert_Einstein_(album) ) and must be allowed. > The description is the tool to make these otherwise indistinguishable > concepts distinguishable in search results and suggesters. > - ( siteid + page ): Each item should describe one (and only one) concept. So > should each linked page. We know this is not true for all pages, but we > decided that not having this constraint would be much more painful than > having it. This reflects what was done with on-page sitelinks before: syncing > sitelinks (e.g. via bot) got screwed if two enwiki pages pointed to the same > dewiki page. The dewiki page can not point back to the two enwiki pages. Yes... Conceptually, every Wikipedia page in each language describes a concept. By Wikipedia rules, there cannot be two pages about the same concept in the same language; nor should a page describe two concepts (though this is a bit more loose). We assume that the same is true for other projects too (Commons, Wikivoyage, etc). Practically, the one-to-one relationship allows us to manage language links semi-automatically, as Thiemo described. > > For a second I wondered if dataTypeId: string should be dataType: DataType, > > but the string is fine. > > > If I'm not mistaken we originally had it like that in the PHP DataModel, but > then moved away from it due to binding that did not provide sufficient value. Conceptually, it refers to a DataType; for the abstract data model, it is not relevant whether this reference is using a string name, or an object reference. That distinction is only relevant for the documentation of the PHP binding. TASK DETAIL https://phabricator.wikimedia.org/T75603 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: thiemowmde, Spage, Abraham, Tobi_WMDE_SW, Snaterlicious, Wikidata-bugs, mkroetzsch, JeroenDeDauw, JanZerebecki, aude, Aklapper, Liuxinyu970226, Lucie, Lydia_Pintscher, daniel _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
