Wikidata:Property proposal/url namespace

URL prefix for search engines

Originally proposed at Wikidata:Property proposal/Authority control

   Withdrawn

Description	URL prefix behind which values of this property can be found using a search engine
Data type	URL
Domain	external id properties without search formatter URL (P4354)
Example 1	Goodreads series ID (P6947)→https://www.goodreads.com/series/
Example 2	TV Maze person ID (P11449)→https://www.tvmaze.com/people/
Example 3	Pocket Casts ID (P9006)→https://pca.st/
Single-value constraint	no
Distinct-values constraint	no

Motivation

Wikidata for Web (Q99894727) offers a feature (find ids) that allows users to search the web for external ids of a given item using search formatter URL (P4354).

This is how it works: Let's say the item you want to find external ids for is Dexter (Q23577). Because this is a television series (Q5398426), the extention assumes it should have a NientePopCorn series ID (P12348) statment. And because this property has a search formatter url it is able to search for the italian label of Dexter (Q23577). Ergo it will open the following link:

https://www.nientepopcorn.it/cerca-un-film/?titolo=Dexter

In the next step the user is able to match the result on the website to the item:

et voila

Why we need this property

This works fairly well for properties that have search formatter URL (P4354) but for those that don't have it I can still use the search engine of the users choice like google or duckduckgo or bing.

John Lennon: Murder Without a Trial (Q123594093) should have a Apple TV show ID (P9751) statement but apple doesn't offer a search on their website. But we actually don't need it because all we need is the url namespace in which the id can be found (https://tv.apple.com/show/) in order to run a query like this in this:

https://duckduckgo.com/?q=John+Lennon%3A+Murder+Without+a+Trial+site%3Ahttps%3A%2F%2Ftv.apple.com%2Fshow%2F&t=ffab&ia=web

In the next step the user is able to match the result on the website to the item:

et voila

The url doesn't actually have to point to anything and often contains a redirect or 404, but for our purpose that doesn't matter.

I am currently misusing URL (P2699) property for this purpose. If you have better suggestions for the name of this property, let me know.  – The preceding unsigned comment was added by Shisma (talk • contribs) at 19:12, 1 February 2024 (UTC).

Discussion

@Back ache, Lucamauri: (recent users of wikidata for web/firefox) –Shisma (talk) 19:15, 1 February 2024 (UTC)

•  Support, an important property for the connectivity of Wikidata.--Arbnos (talk) 20:56, 2 February 2024 (UTC)
•  Support, This could be really important for researchers as (perhaps counterintuitively) external search engines are better at finding information on a site, than the site themselves! Back ache (talk) 08:07, 3 February 2024 (UTC)
• Comment If these need not be resolvable URLs ("often contains a [...] 404"), shouldn't the datatype be string?  – The preceding unsigned comment was added by Pigsonthewing (talk • contribs) at 19:09, 5 February 2024 (UTC).

Courtesy ping @Shisma. Regards Kirilloparma (talk) 13:11, 15 February 2024 (UTC)

I don't understand. it has to be a resolveable url but it may return a redirect or not found. – Shisma (talk) 19:03, 15 February 2024 (UTC)

•  Comment Maybe I’m missing something but − isn’t this the formatter URL (P1630) without the $1? Jean-Fred (talk) 23:00, 8 February 2024 (UTC)

  In many cases yes, but there are execptions. For instance Art Museum of Estonia artist ID (P4563): Using the formatter url yields no results but using the namespace does. – Shisma (talk) 13:34, 9 February 2024 (UTC)

•  Conditional support The name needs to be changed to "url prefix for searches" or something like that. "url namespace" is too generic, and can be confused with other properties like XML namespace URL (P7510). --Tinker Bell ★ ♥ 22:29, 9 February 2024 (UTC)

  agreed –Shisma (talk) 08:32, 10 February 2024 (UTC)

•  Comment. After reading the proposal more carefully, I remembered that there is a gadget like WE-Framework (Q22946134) which uses source website for the property (P1896) for this purpose (screenshot), so I think it may be more than enough in this case as well. @Shisma: What do you think? Regards Kirilloparma (talk) 04:11, 18 February 2024 (UTC)

  I understand that property has:

  ① URL under which humans are able to find this id

  where this proposal says

  ② URL prefix behind which values of this property can be found using a search engine

  These are two entirely diffent scenarios:

  Goodreads series ID (P6947) → https://www.goodreads.com/ (the current value of source website for the property (P1896))

  ① → as a human I can figure out, that I can find works an those works are linked to serieses ✅

  ② → as a search engine I will find all types of entities that happen to have the same title as the series I am looking for ❌

  Goodreads series ID (P6947) → https://www.goodreads.com/series/ (example of this proposal)

  ① → as a human navigating the page I am instantly redirected to the frontpage. this url is not helpful ❌

  ② → as a search engine I will find only serieses ✅

  The aspect of using a search engine with the url in source website for the property (P1896) is not considered by editors, creating this statement. – Shisma (talk) 10:30, 18 February 2024 (UTC)

  @Shisma: Are you really sure you are not detecting any entries using source website for the property (P1896), because I do (see the samples in this video)? Note that this property is not very restrictive and you can add multiple URLs from where you can get the values. Speaking of the data type, if you just want any URL (even a non-working one that leads to nowhere, per above) to search for entries, then why is the data type is URL and not string? Does a string make it somehow harder to retrieve or am I missing something? Regards Kirilloparma (talk) 16:04, 19 February 2024 (UTC)

  It doesn't make it harder. i just think it has to be a valid url, so the url datatype seems appropriate. I don't know 🤷. What do you think?
  
  It sure works for the scenario in the video. It just wouldn't work with Goodreads series ID (P6947). Instead of a new property we could also just add a particular set of qualifiers to a url that can be used like I intend. – Shisma (talk) 17:12, 19 February 2024 (UTC)

  Yes, I would just use object has role (P3831) as qualifier. --Horcrux (talk) 15:24, 20 February 2024 (UTC)

  what should be the object of this qualifier? Shisma (talk) 16:40, 20 February 2024 (UTC)

  I guess an ad-hoc item having as label the name indicated above for this proposal. --Horcrux (talk) 12:02, 21 February 2024 (UTC)

  That seems fair. I have withdrawn this proposal in favor of this solution. @Tinker Bell, Back ache, Arbnos, Horcrux, Kirilloparma: thanks for your considerations – Shisma (talk) 16:48, 24 February 2024 (UTC)

•  Comment I changed the proposed name to "URL prefix for search engines". It is important to explicit that we are talking about seaching by using some web search engine (Q4182287). --Horcrux (talk) 15:24, 20 February 2024 (UTC)