[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
daniel added a comment. Sounds like you are re-inventing what wikidata calls "constraints" - have a look at https://www.wikidata.org/wiki/Help:Property_constraints_portalTASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. @daniel sorry, let me clarify. The goal is to use Wikbase as a secondary documentation (metadata) for the tags, not as a tag storage replacement. We need to describe each tag, describe how they relate to each other, provide localized documentation, etc. OSM has multiple key-value tags (strings) for each object. The string keys could be represented by Wikibase entities (with some hacking to use string instead of integers to ID, per above). Some of these tags use "free form" values - like address - there is no need to store/document these in Wikibase, but we may store some validation information in the tags itself (e.g. store some regex in the "zip code" tag) Some other tags like religion imply a predefined list of values (enum). As you can see, there is currently a big list on that page, and that list could be stored in Wikibase. So the question is - should that list of values be stored as statements on the "religion" tag, or use a more flexible approach to store each as a separate entity, possibly in a separate namespace. Storing them as statements may make that entry too big (hundreds), and not offer enough flexibility. For example, for religion=pagan -- pagan should link to Wikidata's entry, and also may link to some other key to specify that it should/shouldn't be used with that, or it may point to another value as a redirect. So if values are stored in a separate namespace, what would be the good way to identify them? One way could be "religion=pagan" form -- include both the tag key and value. But this is bad because renaming is hard... so unsure of the best approach...TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
daniel added a comment. @Yurik now you lost me. "relgion" isn't a unique ID. And it should be editable. Why not use a regular statement? That's what we do on wikidata. But this seems to be entirely unrelated to this ticket. Also, address may be unique (if you include enough detail), "name" certainly isn't. I'm nut sure I understand what problem you are trying to solve.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. @daniel this is awesome, thanks! The sitelink hack would probably be the best approach for the tag keys (e.g. name, address etc.) I am not yet sure of the best approach for the "enum-like" values -- some tags, e.g. religion tend to have a well-known list of values. It would be good to have a separate namespace for all the possible values for them. Enforcing uniqueness for them does not make sense -- same value could be used for more than one tag, and could have very different meaning. One option to store tag value would be to allow duplicates (use a regular string property to store the actual value), to reference all tag entities, and to use a bot to ensure that tags are referenced only ones per each unique value. Or it could be some on-db-update check...TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Pigsonthewing, Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
daniel added a comment. Oh, I just realized. You could fake this using a fake sitelink. On wikidata, an item's sitelinks points to articles in sister projects like wikipedia. It should not be hard to allow pages on non-mediawiki sites to be references in the same way - or even just pretend to reference a page. Sitelinks are unique, and can even be used to address items in the API.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Yurik added a comment. thx, clearly this wouldn't be used for wikidata. @daniel could you point me to the relevant code plz, or perhaps something similar, or maybe sketch the implementation approach? I was thinking that this would be the only real path to solve this, possibly with a custom database table to prevent accidental duplicates.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: YurikCc: Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
daniel added a comment. For a 3rd party site, it would not be terribly hard to implement a new entity type that extends the Item type to have an additional immutable string ID. This would be done by a custom extension on top of Wikibase. I don't think we'd deploy such a thin on Wikidata, though - we'd end up with hundreds of such custom types that only differ by a handful of fields, which with it's own slightly different logic.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Lydia_Pintscher, Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192249: Support for non-integer Wikidata IDs (or alternative)
Micru added a comment. So if I understand correctly, you would like to have custom Entity IDs instead of the usual Q followed by an integer (Q). On Wikidata normally the Entity IDs are not visible, what the user sees is the label of the entity. So I assume that in the use case of OSM you could have an entity with all the labels with the same string value for all languages, which could be enforced with a bot. That way you can maintain the value of the tag or change it when necessary.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MicruCc: Micru, Aklapper, daniel, Yurik, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
