Wikidata:Property proposal/SPARQL endpoint

SPARQL endpoint URL

Originally proposed at Wikidata:Property proposal/Generic

   Done: SPARQL endpoint URL (P5305) (Talk and documentation)

Description	URL of the SPARQL endpoint of the database/website
Represents	SPARQL endpoint (Q26261192)
Data type	URL
Example	Wikidata (Q2013) → https://query.wikidata.org/sparql
See also	official website (P856), web feed URL (P1019)

Motivation

Seems preferable over other solution, such as adding a second value to P856 and attempting to qualify it.
--- Jura 12:53, 6 June 2018 (UTC)

Discussion

 Support, looks useful − Pintoch (talk) 10:56, 7 June 2018 (UTC)

•  Support David (talk) 12:59, 7 June 2018 (UTC)
•  Support Why not, though it's always struck me as odd that something so "web centric" (Semantic web and all that) still needs to be located via its own URL rather than the web somehow "knowing" about it... ArthurPSmith (talk) 13:27, 7 June 2018 (UTC)
•  Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 7 June 2018 (UTC)
•  Oppose A generic property "API endpoint" would be more helpful to get access information to a database. Qualifier protocol (P2700) already exists, values can be SPARQL (Q54871), Open Archives Initiative Protocol for Metadata Harvesting (Q2430433), Search/Retrieve via URL (Q337367), Z39.50 (Q135847), GraphQL (Q25104949), OAuth (Q743238)... It could also link no non-standard APIs (e.g http://en.wikipedia.org/w/api.php). -- JakobVoss (talk) 09:05, 8 June 2018 (UTC)

I think JakobVoss has a good idea here - why don't we try a more generic property like that. If we get an overwhelming number for a particular protocol we could split that off separately as its own property, as we've done in some other cases before. ArthurPSmith (talk) 18:04, 8 June 2018 (UTC)

Oa01 pointed out that URL (P2699) is already being used for that here: Q5674339#P2699. Do we even need a new property for API endpoints or should we just use that? − Pintoch (talk) 11:12, 9 June 2018 (UTC)

I first though URL (P2699) and qualifiers is enough but it turns out to be difficult to query API endpoints when no standard protocol has been defined (e.g. custom REST APIs). I'd prefer a dedicated property for API endpoints as subproperty of URL (P2699) -- JakobVoss (talk) 12:43, 9 June 2018 (UTC)

@Jura1: Would you consider this generalization? Lymantria (talk) 05:27, 13 June 2018 (UTC)

I think we already have more general properties that can be used in the suggested way (some were suggested for that). So there wouldn't really be the need for an additional one. The advantage of this proposal is that we wont have to repeat a basic aspect of sparql on every node. Details, if needed, can be added to the property itself.
--- Jura 05:32, 13 June 2018 (UTC)

URL (P2699) is too specific to query generic API endpoints independent of the protocol, this should justify an "API endpoint" property. -- JakobVoss (talk) 06:44, 13 June 2018 (UTC)

•  Support I agree with JakobVoss concerning the name. It's better to rename this property 'API endpoint' and make use of protocol. John Samuel 20:08, 11 June 2018 (UTC)

@Jura1, Pintoch, ديفيد عادل وهبة خليل 2, ArthurPSmith, JakobVoss, Pigsonthewing:@John Samuel:  Done for the narrow proposal, now SPARQL endpoint URL (P5305). A broader approach can be discussed later, SPARQL endpoint URL (P5305) might become a subproperty of that one. Lymantria (talk) 08:01, 13 June 2018 (UTC)

@Jura1, Pintoch, ديفيد عادل وهبة خليل 2, ArthurPSmith, JakobVoss, Pigsonthewing:@John Samuel: Sorry, this procedure is not right, we had an ongoing discussion and no reason to hurry. Please delete the property and let's exchange arguments and examples first: Wikidata:Properties_for_deletion#SPARQL_endpoint_(P5305) -- JakobVoss (talk) 13:27, 13 June 2018 (UTC)

Scope of this property

This property was created by accident before rough consensus could be reached, whether to have a specific property for SPARQL endpoints or a more generic property for API endpoints and a qualifier for SPARQL protocol. Let's collect arguments to find a solution that everybody can work with! -- JakobVoss (talk) 21:17, 13 June 2018 (UTC)

@JakobVoss: given the deletion discussion I think at this point it's best to just propose this as a separate property, I think you'll get some support! ArthurPSmith (talk) 14:39, 15 June 2018 (UTC)

Arguments for/against SPARQL specific property

•  Support it's easier to express and query SPARQL endpoints (the particular use case of this property) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)

Arguments for/against generic API endpoint property

•  Support API's are intended for machine interaction and so making that distinction from our existing URL properties is useful; there are many protocols, and in fact a lot of places have custom protocols defined by something like OpenAPI Specification (Q18393146). ArthurPSmith (talk) 15:40, 14 June 2018 (UTC)
•  Support I likee the idea that protocols can be defined just by their Qid - this potentially lets us make interesting SPARQL queries. − Pintoch (talk) 13:47, 15 June 2018 (UTC)
•  Support So we can record API endpoints in general. It seems intuitive that we should create more generic properties first, then create more specific sub-properties as required. Deryck Chan (talk) 13:08, 18 June 2018 (UTC)
•  Support for generic properties first, big number of protocols and ease of specifying protocols as mentioned (it seems to get a voting here now more than a collection of arguments, so I want to use it this way …:) ). --Marsupium (talk) 13:33, 20 June 2018 (UTC)

Arguments for/against both "SPARQL endpoint" and "API endpoint" properties

•  Oppose more difficult to query all API endpoints because SPARQL is additional property to explicitly query for (subproperties are not included automatically) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)
•  Question What services will have separate SPARQL and API endpoints? If that were the case, will the API endpoints all need object has role (P3831) to clarify what APIs they are? Taking Wikidata as an example, one may also argue that the API endpoint is https://www.wikidata.org/w/api.php is the endpoint for Wikidata, whereas https://query.wikidata.org/sparql is actually the API endpoint for the Wikidata Query Service. Deryck Chan (talk) 17:13, 18 June 2018 (UTC)

Arguments for/against having none of them

•  Oppose The property creation proposal above clearly demonstrated it will be useful to have at least one new property to record SPARQL endpoints, either with a "SPARQL endpoint" property or with an "API endpoint" property. --Deryck Chan (talk) 15:56, 15 June 2018 (UTC)
•  Oppose more difficult to express and query API endpoints (always need to check qualifier, use special qualifier value "unknown" for unknown protocol) -- JakobVoss (talk) 19:57, 15 June 2018 (UTC)