Wikidata:Property proposal/SPARQL endpoint

From Wikidata
Jump to navigation Jump to search

SPARQL endpoint URL

[edit]

Originally proposed at Wikidata:Property proposal/Generic

DescriptionURL of the SPARQL endpoint of the database/website
RepresentsSPARQL endpoint (Q26261192)
Data typeURL
ExampleWikidata (Q2013) → https://query.wikidata.org/sparql
See alsoofficial 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)[reply]

Discussion

 Support, looks useful − Pintoch (talk) 10:56, 7 June 2018 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@Jura1: Would you consider this generalization? Lymantria (talk) 05:27, 13 June 2018 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]

Scope of this property

[edit]

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)[reply]

@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)[reply]

Arguments for/against SPARQL specific property

[edit]

Arguments for/against generic API endpoint property

[edit]
  •  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 (Q18393146). ArthurPSmith (talk) 15:40, 14 June 2018 (UTC)[reply]
  •  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)[reply]
  •  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)[reply]
  •  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)[reply]

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

[edit]

Arguments for/against having none of them

[edit]
  •  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)[reply]
  •  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)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/SPARQL_endpoint&oldid=699061281"