Shortcuts: WD:PP/COMP, WD:PP/Computing
Wikidata:Property proposal/Computing
Property proposal: | Generic | Authority control | Person | Organization |
Creative work | Place | Sports | Sister projects | |
Transportation | Natural science | Computing | Lexeme |
See also
[edit]- Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
- Wikidata:Properties for deletion – proposals for the deletion of properties
- Wikidata:External identifiers – statements to add when creating properties for external IDs
- Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata
This page is for the proposal of new properties.
Before proposing a property
- Search if the property already exists.
- Search if the property has already been proposed.
- Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
- Select the right datatype for the property.
- Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
- Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.
Creating the property
- Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
- Creation can be done 1 week after the creation of the proposal, by a property creator or an administrator.
- See property creation policy.
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/08. |
General
[edit]serves resource
[edit]Motivation
[edit]This proposal seeks to introduce a way to model the HTTP routes of web interfaces (be they web user interfaces or web APIs).
The semantics of HTTP routes are very much of interest for:
- web search engines which want to understand the function of a particular web page
- web crawlers which want to crawl the web for resources of a specific type, or want to avoid crawling resources of a specific type, or want to crawl resources of a specific type more/less frequently than resources of another specific type
- hyperlinking, creating a hyperlink to a specific resource within a specific context
- this enables other useful properties e.g. adding references to git commits only via their commit hash, see Wikidata:Property proposal/changeset
- this enables very useful userscripts e.g. you could have a button that automatically takes you to the API endpoint for the specific resource you're currently viewing
- evaluating compatibility between web interfaces
- providing compatibility e.g. if you self-host a cgit (Q28974765) instance but decide that you want to switch to a self-hosted GitLab (Q16639197) instance. If the semantics of their most important routes were modeled in Wikidata, there could be a script that automatically generates an nginx (Q306144) config for you to provide server-side redirects from the old cgit routes to the GitLab routes (or vice versa if you were to switch in the opposite direction)
Description
[edit]To achieve that this proposal proposes one property for data items and three accompanying qualifer-only properties.
The core idea is that URL suffix formatter
can be used to qualify under which URL suffix the resource is served,
as with formatter URL (P1630) $1
can be replaced with the identifier of the resource.
Since resources are often hierarchical we also introduce a parent resource
qualifier with the following semantics:
- Xserves resourceapple
URL suffix formatter/apples/$1 - Xserves resourceorange
URL suffix formatter/oranges/$1 parent resourceapple
means that oranges are served at /apples/$appleId/oranges/$orangeId
.
Our system is already powerful enough to model the majority of HTTP routes of many web interfaces, however there are two things we currently do not cover:
- some HTTP routes cannot modeled in this way, e.g. imagine that the route instead was
/apples/$orangeId/$appleId
- some resources have multiple kinds of identifiers (e.g. a Phabricator project has a slug (Q99601940) as well as a numeric identifier (Q93868746))
We can address both concerns by introducing a fourth and last qualifying property "URL parameter", with the following semantics:
- Xserves resource...
URL suffix formatter/users/$user URL parameterusername (Q15901043) means that $user
should be a username (Q15901043) - Xserves resource...
URL suffix formatter/users/$user URL parameternumeric identifier (Q93868746) means that $user
should be a numeric identifier (Q93868746) - Xserves resource...
URL suffix formatter/example/$foo/$bar URL parameterversion control branch (Q925385) URL parameterpath (Q817765) means that $foo
should be a version control branch (Q925385) and$bar
should be a path (Q817765)
The names of the placeholders do not matter, what matters is that they are in the same order as the "URL parameter" qualifiers.
Cheers, Push-f (talk) 00:21, 21 November 2022 (UTC)
Discussion
[edit]WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Notified participants of WikiProject Websites. --Push-f (talk) 00:33, 21 November 2022 (UTC)
Support, great proposal. I do wonder if we're stretching the limits of what Wikidata can represent, especially when it comes to the ability of human editors to build the knowledge subgraphs when modeled to such detail and complexity. This should not be a blocker for adopting this proposal, mind you, but we should probably consider having detailed examples and maybe even a diagram or two to help editors understand how these properties are meant to be used. Otherwise we may end up with a situation similar to the modeling of books which is famously inconsistent in Wikidata as it clashes with people's intuition about what a book is. – The preceding unsigned comment was added by Waldyrious (talk • contribs).
- Thanks! Yes I agree about these properties needing thorough documentation; on top of that I will probably develop a user script to view the routes implied by the proposed properties :) --Push-f (talk) 09:40, 21 November 2022 (UTC)
Comment Very solid and thoughtful proposal. However, your examples show that storing this information in Wikidata and consuming it can be kinda awkward. Consider creating your own specialized database that we can link to from Wikidata ;) Dexxor (talk) 17:52, 22 November 2022 (UTC)
- Thanks :) Wikibase isn't easy to self-host[1] and this is without getting into setting up a Blazegraph (Q20127748) server so that you can still query the data with SPARQL and setting up some third-party login to lower the barrier to entry ... but even then I think people are more likely to contribute to Wikidata than some niche database.
- Besides with the right tooling I think this proposal could really address a fundamental problem of Wikidata, which is that we don't want to create a bunch of properties for every website/common HTTP route out there. Have you looked at my changeset proposal? There @Dexxor: argued that "changeset formatter URL suffix" is too specific, so I withdrew that idea in favor of this more reusable and powerful approach. I guess another example is also my Wikimedia Phabricator project proposal where @Arlo Barnes: has argued that a more general property would be better.
- So I think the solution is to develop specialized tooling for these properties in Wikidata (e.g. user scripts for contributors and libraries/bots for consumers), rather than outsourcing that data somewhere else entirely.
- --Push-f (talk) 10:00, 23 November 2022 (UTC)
On hold Apparently qualifiers of data type item are unordered, so the "URL parameter" idea doesn't work. The best alternative I can think of would be encoding the parameter class IDs directly into the URL suffix formatter, e.g. ${Q6} ... however encoding item IDs into string obviously isn't ideal. --Push-f (talk) 02:30, 27 November 2022 (UTC)
URL suffix formatter
[edit]Description | (qualifier only) under which URL suffix the resource is served; "$1" can be automatically replaced with the identifier of the resource; if the template requires additional parameters they may be specified as other placeholders matching the regular expression \$[a-z]+, in this case the data types of the parameters must be qualified with "URL parameter" |
---|---|
Data type | String |
Domain | may only be used as a qualifier for "serves resource" |
Example 1 | see #serves resource |
Example 2 | see #serves resource |
Example 3 | see #serves resource |
See also | formatter URL (P1630) |
See #serves resource for the motivation and discussion.
parent resource
[edit]Description | (qualifier only) indicates that this resource is a subresource of the given resource (and that the "URL suffix formatter" of the given resource comes before the "URL suffix formatter" of this resource) |
---|---|
Data type | Item |
Domain | may only be used as a qualifier for "serves resource" |
Example 1 | see #serves resource |
Example 2 | see #serves resource |
Example 3 | see #serves resource |
See #serves resource for the motivation and discussion.
URL parameter
[edit]Description | (qualifier only) meant to qualify the data types of placeholders in "URL suffix formatter" values; if there are several URL parameters this qualifier must be specified multiple times in the same order that the URL parameter placeholders appear in the "URL suffix formatter" value |
---|---|
Data type | Item |
Domain | may only be used as a qualifier for "serves resource" |
Example 1 | see #serves resource |
Example 2 | see #serves resource |
Example 3 | see #serves resource |
See #serves resource for the motivation and discussion.
Wikimedia Phabricator project PHID
[edit]Description | PHID of the Wikimedia Phabricator project for the subject |
---|---|
Data type | External identifier |
Example 1 | Wikibase Repository (Q21679301) → vumw5jyyw4r3fv52k34y |
Example 2 | Extension:Wikibase Client (Q21679293) → 46yqqwzqvnxmbabmz3tc |
Example 3 | Pywikibot (Q15169668) → orw42whe2lepxc7gghdq |
Formatter URL | https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-$1&statuses=open()&order=newest#R |
See also | issue tracker URL (P1401), Wikimedia Incubator URL (P9748) |
Motivation
[edit]Most MediaWiki software uses https://phabricator.wikimedia.org/ as its issue tracker. Currently the issue trackers are linked via issue tracker URL (P1401), which is however a bit messy since there are many different ways to link to a project on Phabricator:
- by project slug, e.g: https://phabricator.wikimedia.org/tag/pywikibot/
- by numeric id, e.g: https://phabricator.wikimedia.org/project/board/87/
- by PHID, e.g: https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-orw42whe2lepxc7gghdq
While project slugs are the most human-friendly of these, project slugs can change and one project can have multiple slugs, making them suboptimal for a Wikidata identifier property. So the choice remains between the numeric ids and the PHIDs. I think PHIDs are the clear winner because the Phabricator API to search tasks maniphest.query only accepts PHIDs for projects and we don't want to force data consumers to do a project.query lookup to translate the id to the PHID every time they want to query the tasks of a project.
How to find the PHID? If you are at a project page, click on Open Tasks and then you can find the PHID in the URL.
A bot could be written to import these identifiers from https://www.mediawiki.org/, because it has the project slugs in various templates:
- mw:Template:Ptag
- mw:Template:Extension#phabricator
- mw:Template:Wikimedia engineering project information
- mw:Template:Software
Cheers, --Push-f (talk) 16:09, 21 November 2022 (UTC)
Discussion
[edit]Notified participants of WikiProject Websites. --Push-f (talk) 16:12, 21 November 2022 (UTC)
- Note the project name is not stable, but the ID is. Consider linking to e.g. https://phabricator.wikimedia.org/project/profile/114/ --GZWDer (talk) 17:13, 21 November 2022 (UTC)
- Thanks for bringing that up! I have updated this proposal to use PHIDs instead of project slugs (see the updated motivation for my reasoning). --Push-f (talk) 17:49, 21 November 2022 (UTC)
Support -wd-Ryan (Talk/Edits) 18:05, 21 November 2022 (UTC)
Comment Would there be a way to use a prefix to make this useful more generically, for other Phab/Phorge instances? Arlo Barnes (talk) 18:58, 21 November 2022 (UTC)
- Yes we could of course introduce more generic properties e.g:
- And then making use of my proposed serves resource scheme:
- Phabricator (Q16509734)serves resourceissue list (Q03)
URL suffix formatter/maniphest/?project=PHID-PROJ-$1&statuses=open()&order=newest#R URL parameterPhabricator project PHID (Q04)
- Phabricator (Q16509734)serves resourceissue list (Q03)
- And the new property would have: Phabricator project PHID (P02)Wikidata item of this property (P1629)Phabricator project PHID (Q04).
- This would be flexible enough to be used for any Phabricator instance. Figuring out the issue tracker URL (P1401) for Wikibase Repository (Q21679301) from these statements however is a bit more involved.
- I think that could be addressed by introducing a bot that automatically derives the issue tracker URL (P1401) from these statements and updates e.g. Wikibase Repository (Q21679301) accordingly when they are changed.
- --Push-f (talk) 10:27, 23 November 2022 (UTC)
Support. Nomen ad hoc (talk) 07:05, 22 November 2022 (UTC).
Comment Not that I oppose this, but aren't wikimedia projects moving from Phabricator to Gitlab sometime soon? ArthurPSmith (talk) 19:27, 29 November 2022 (UTC)
- No, the plan is to move the code review from Gerrit to GitLab, Phabricator will as far as I know be kept for issue tracking, see phab:T264231, phab:T265617 and mw:GitLab/Roadmap. --Push-f (talk) 20:03, 29 November 2022 (UTC)
On hold I want to know opinions if we should instead introduce a more general property that can also be used for other Phabricator instances, as suggested by Arlo Barnes above. --Push-f (talk) 20:06, 29 November 2022 (UTC)
Support --Wüstenspringmaus talk 14:15, 3 June 2024 (UTC)
xdaforums.com
[edit]Description | identifier for a page in xdaforums.com |
---|---|
Data type | External identifier |
Example 1 | Redmi Note 2 (Q21017083)→[2] |
Example 2 | POCO X3 Pro (Q117280924)→[3] |
Example 3 | Samsung Galaxy S10 (Q60021939)→[4] |
External links | Use in sister projects: [ar] • [de] • [en] • [es] • [fr] • [he] • [it] • [ja] • [ko] • [nl] • [pl] • [pt] • [ru] • [sv] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt]. |
Formatter URL | https://xdaforums.com/c/$1 |
Single-value constraint | yes |
Distinct-values constraint | yes |
Motivation
[edit]xda is a big and important source of useful information about Android devices, also about LineageOS development for a specific devices. – The preceding unsigned comment was added by Vitaly Zdanevich (talk • contribs).
Discussion
[edit]Comment The slug is not needed. For example, https://xdaforums.com/f/xiaomi-poco-x3-pro.12163/ -> https://xdaforums.com/f/12163/. -wd-Ryan (Talk/Edits) 13:57, 25 July 2024 (UTC)
Comment it needs to be called xdaforums IDVicarage (talk) 17:55, 5 August 2024 (UTC)