Wikidata talk:Property proposal
Add topic
 Archives | |||
|---|---|---|---|
| |||
all subpages · all talk subpages
This page concerns mainly the property creators. Don't start discussion about property proposal here
Proposal review request
[edit]I came up with a reasonably sizable set of statements to add, which is ready to be added right now, but then I realized that it probably needs a new property before I can add them. I'd appreciate it if people could review Wikidata:Property proposal/Performing organization quickly so I can actually add the data. Thanks. John P. Sadowski (NIOSH) (talk) 05:01, 12 February 2024 (UTC)
Request for Feedback on New Property Proposal
[edit]Last September, I submitted a property proposal titled 'KISTI institute ID' in Wikidata:Property_proposal/Organization but it has not received any support for creation and is currently marked as 'Not Done.' If there are any issues with the proposal, please let me know what needs to be corrected. If there are no issues, I kindly request your support for the proposal. KISTI Data (talk) 05:18, 15 October 2024 (UTC)
New top-level namespace for IDs?
[edit]Similar to Q: and P:, should we have ID: or K: for identifiers in other systems == foreign keys?
In the first 200 properties there are no IDs. Then VIAF and GND were added. By the time you get to the 10,000th property, only 1 of the next 20 properties is not an ID.
IDs have significantly different properties, validation options, and constraints than other properties, and they make any statistics or analysis of semantic properties extremely difficult harder. Moreover most queries do not care about such IDs and may be easily classified as such; there may be natural optimizations to improve performance for them especially for entity types that have long lists of IDs.
Has this been discussed already elsewhere? Sj (talk) 22:59, 10 December 2025 (UTC)
- It's very easy to spot an external id through its data type, and hence also almost trivial to filter it from queries. For example, here is a query with all properties except External identifiers. So while moving them to a different namespace would give you a way for filtering, we already have one and I think you may need to describe a more concrete use case where the data type is not enough. (If you need help with a specific query where you have trouble because external identifiers are showing up in the results, I would be more than happy to assist.) Ainali (talk) 11:55, 11 December 2025 (UTC)
- I don't think there's any need for this. There is some overlap between string-valued properties and external-id properties anyway. We already segregate the id properties in the UI here. External ID properties are approved at a high rate these days because they are quite simple to implement. ArthurPSmith (talk) 19:44, 11 December 2025 (UTC)
- Such a change would obviously be very disruptive, so would require a strong case. Could you explain some examples of things that would be possible (or easier) under this scheme than they are today? I think you point in the direction of one, which is that values expected to be unique (hapax) can be indexed differently, but you need a much stronger case.
- I note that's it's not always clear what counts as an identifier, and we do occasionally have to convert properties from one to the other.
- Identifiers are slippery things. Here are some things that people expect of identifiers, which they don't always have:
- If two entities have the same identifier, they are the same entity
- If two entities have different identifiers within the same scheme, then they are different entities.
- Having a restricted format
- Resolvable to external information about the entity (but usually not URLs directly)
- Reciprocal, in that many identifier authorities will also store our item identifier
- Persistent, never reassigned, but possibly deleted/deprecated or merged
- Bovlb (talk) 21:13, 11 December 2025 (UTC)
- Thanks all. @Ainali: you're right, adding a two-line filter makes most queries straightforward. It just feels like a semantically different thing, which also completely dominates the namespace, so that most things stored as a {property of an entity} aren't traditional properties at all but cross-references among different catalogs. Sj (talk)
- I don't think there's any need for this. There is some overlap between string-valued properties and external-id properties anyway. We already segregate the id properties in the UI here. External ID properties are approved at a high rate these days because they are quite simple to implement. ArthurPSmith (talk) 19:44, 11 December 2025 (UTC)