Wikidata:Property proposal/API endpoint

API endpoint edit

Originally proposed at Wikidata:Property proposal/Generic

Done: API endpoint URL (P6269) (Talk and documentation)

Description	base URL of a web service
Data type	URL
Domain	data set (Q1172284), web service (Q193424)
Example 1	Wikidata (Q2013) → https://www.wikidata.org/w/api.php (no standard protocol)
Example 2	Library of Congress (Q131454) → "unknown" qualifier described at URL (P973) https://libraryofcongress.github.io/data-exploration/
Example 3	Library of Congress (Q131454) → http://lx2.loc.gov:210/LCDB qualifier protocol (P2700) Search/Retrieve via URL (Q337367)
Example 4	GitHub (Q364) → https://api.github.com/graphql qualifier protocol (P2700) qualifier described at URL (P973) https://developer.github.com/v4/
Example 5	GitHub (Q364) API → https://api.github.com (no standard protocol) qualifier file format (P2701) JSON (Q2063)
Source	websites of each item and third-party directories such as https://www.programmableweb.com/apis/directory
See also	SPARQL endpoint URL (P5305), web feed URL (P1019), URL (P2699)

Motivation

Specify API endpoints to access databases via web services. Standard protocols can be added with qualifier protocol (P2700) and link to API documentation with qualifier described at URL (P973). This property was also discussed as part of Wikidata:Property proposal/SPARQL endpoint. API endpoints can already be specified with URL (P2699) and qualifier protocol (P2700) but many endpoints don't follow a standard protocol and it's more convenient to query endpoints without qualifier. -- JakobVoss (talk) 06:58, 16 June 2018 (UTC)[reply]

Discussion

Support David (talk) 19:17, 16 June 2018 (UTC)[reply]
Can this also be used to resolve the issue raised at Wikidata:Project chat#Formatter URL for XML? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 16 June 2018 (UTC)[reply]
- Yes, that is exactly the sort of thing this property would be used for, providing machine-readable data in a standard format (in that case I assume some specific XML protocol?) ArthurPSmith (talk) 14:44, 18 June 2018 (UTC)[reply]
  - On further examination, it cannot, because this proposal is for property with a URL datatype, not a string with a $1 component. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:23, 20 June 2018 (UTC)[reply]
Comment What would be the usecase for such a property? To some extent this duplicates Wikidata:Property proposal/Archive/48#P2699 or a simple selection by property datatype.
--- Jura 09:07, 17 June 2018 (UTC)[reply]

Support (but please don't support your own proposal - it makes it clearer to assess at a glance if there is consensus) − Pintoch (talk) 08:23, 18 June 2018 (UTC)[reply]

Support ArthurPSmith (talk) 14:44, 18 June 2018 (UTC)[reply]

Oppose duplicates the existing property proposed at Wikidata:Property proposal/Archive/48#P2699. I don't think it can work work as intended by the proposer ("it's more convenient to query endpoints without qualifier."). Maybe it's just that the use case isn't specified.
--- Jura 06:15, 19 June 2018 (UTC)[reply]

This makes no sense to me: you just argued the opposite at Wikidata:Property proposal/SPARQL endpoint -- JakobVoss (talk) 21:07, 20 June 2018 (UTC)[reply]

I don't think I did, but it's possible that I just don't understand your usecase. As you haven't given it, that seems normal. So what do you want to do with this property that you can't do with the one proposed for the same at Wikidata:Property proposal/Archive/48#P2699. Please include a sample query and application.
--- Jura 04:05, 21 June 2018 (UTC)[reply]

Support - Bit sad that we already have SPARQL endpoint URL (P5305), because this seems to be much more versatile. Husky (talk) 19:20, 19 June 2018 (UTC)[reply]

Support - I actually like that we have SPARQL endpoint URL (P5305) as well, because I think that a SPARQL endpoint has particularly strong relevance for people working with Wikidata. But I do think this property is a useful distinction over generic URL (P2699) -- an API for data extraction is a very specific sort of URL, that it is useful to separate from other sorts of URLs the site may offer; and the API URL statements are already going to be quite complicated, with quite a lot of potential qualifiers flying around. It's a lot cleaner to be able to consider them separately, without them being muddled together with all sorts of other URLs, with all sorts of other role-specific qualifiers. Jheald (talk) 21:05, 19 June 2018 (UTC)[reply]

Oppose As noted above, this duplicates URL (P2699), whose documentation should be clarified. It may, though, be useful to have a new property with an $1 component. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:23, 20 June 2018 (UTC)[reply]

@Pigsonthewing: More accurately, it's a specialisation of P2699 rather than a duplication. This property is proposed to segregate off a specific subset of things currently loaded on the reserve backstop property URL (P2699). Jheald (talk) 11:06, 20 June 2018 (UTC)[reply]

Support. ··· 🌸 Rachmat04 · ☕ 07:52, 7 August 2018 (UTC)[reply]
Support API endpoints are offered by web services to interact with or extract information, and it's specialized as feed URL or SPARQL endpoint --Sabas88 (talk) 12:52, 4 September 2018 (UTC)[reply]
Support Worldm99 (talk) 08:36, 18 September 2018 (UTC)[reply]

@ديفيد عادل وهبة خليل 2, JakobVoss, Pigsonthewing, ArthurPSmith, Jura1:@Husky, Jheald, Rachmat04, Sabas88, Worldm99: Done--Micru (talk) 12:55, 19 December 2018 (UTC)[reply]