मा -----Original Message----- From: "Stas Malyshev" <smalyshev(a)wikimedia.org> Sent: ‎24-‎08-‎2016 12:33 AM To: "Discussion list for the Wikidata project." <wikidata(a)lists.wikimedia.org> Subject: Re: [Wikidata] A property to exemplify SPARQL queries associated witha property Hi! Might be nice, but we need a good way to present the query in the UI (see below). I think it may be a good idea to start thinking about some way of storing queries on Wikidata maybe? On one hand, they are just strings, on the other hand, they are code - like CSS or Javascript - and storing them just as strings may be inconvenient. Maybe .sparql file extension handler like we have for .js and .json and so on? -- Stas Malyshev smalyshev(a)wikimedia.org _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

example sparql queries alone can be very helpful but I would suggest that they can be accompanied with a short description explaining what the query does On Wed, Aug 24, 2016 at 3:21 PM, Navino Evans <navino(a)histropedia.com> wrote: -- Kontokostas Dimitris

Hoi, For many categories we have exactly that in Reasonator. This functionality is based on "is a list of". It functions not for all categories or all content for a category. Wikidata often shows more data particularly when the categories from "other" Wikipedias have been harvested. It would be relatively easy to continuously harvest data from Wikipedias based on such categories. Thanks, GerardM https://tools.wmflabs.org/reasonator/?q=Q8328346 On 24 August 2016 at 14:21, Navino Evans <navino(a)histropedia.com> wrote:

Hoi, It is particularly interesting to do this for categories or lists. In this way it is immediately obvious that queries are more inclusive than categories or lists. But that is not the only opportunity. When you consider the best practice that Reasonator offers, you will find that it show all the relations that exists to the item in question. So for an award it will show all the items that have "award received" for instance. Really useful as it also sorts them by date when there is a qualifier with "point in time" for it. It would be good if Wikidata would consider these best practices. Thanks, GerardM On 25 August 2016 at 08:37, Markus Kroetzsch &lt;markus.kroetzsch(a)tu-dresden.de > On 25.08.2016 07:40, Gerard Meijssen wrote: > >> Hoi, >> For many categories we have exactly that in Reasonator. This >> functionality is based on "is a list of". >> > > Yes, I was thinking of this when making this proposal. The thing is that > "is a list of" is not a very powerful way to describe lists. It can only do > very simple things. Examples like the "list of inventors killed by their > own invention", which are easy to do in SPARQL, are not possible there. > > I should add that there are also problems with having arbitrary SPARQL > queries. They are on the other end of the sprectrum from where "is a list > of" is: they can express too much details (sorting order, label recall, > query optimiser settings, etc.). When using SPARQL for list descriptions, > the community should try to use the simplest query possible without any > extras for formatting and sorting, or it will again be hard to use this. > > Markus > > > It functions not for all > >> categories or all content for a category. Wikidata often shows more data >> particularly when the categories from "other" Wikipedias have been >> harvested. >> >> It would be relatively easy to continuously harvest data from Wikipedias >> based on such categories. >> Thanks, >> GerardM >> >> https://tools.wmflabs.org/reasonator/?q=Q8328346 >> >> On 24 August 2016 at 14:21, Navino Evans &lt;navino(a)histropedia.com >> <mailto:navino@histropedia.com>>> >> If you could store queries, you could also store queries for >> each item that is about a list of things, so that the query >> returns exactly the things that should be in the list ... could >> be useful. >> >> >> This also applies to a huge number of Wikipedia categories (the non >> subjective ones). It would be extremely useful to have queries >> describing them attached to the Wikidata items for the categories. >> >> On 24 August 2016 at 02:31, Ananth Subray &lt;ananth.subray(a)gmail.com >> <mailto:ananth.subray@gmail.com>>> >> मा >> ------------------------------------------------------------ >> ------------ >> From: Stas Malyshev <mailto:smalyshev@wikimedia.org> >> Sent: ‎24-‎08-‎2016 12:33 AM >> To: Discussion list for the Wikidata project. >> <mailto:wikidata@lists.wikimedia.org> >> >> Subject: Re: [Wikidata] A property to exemplify SPARQL queries >> associated witha property >> >> Hi! >> >> > Relaying a question from a brief discussion on Twitter [1], I >> am curious >> > to hear how people feel about the idea of creating a a "SPARQL >> query >> > example" property for properties, modeled after "Wikidata >> property >> > example" [2]? >> >> Might be nice, but we need a good way to present the query in the >> UI >> (see below). >> >> > This would allow people to discover queries that exemplify how >> the >> > property is used in practice. Does the approach make sense or >> would it >> > stretch too much the scope of properties of properties? Are >> there better >> > ways to reference SPARQL examples and bring them closer to >> their source? >> >> I think it may be a good idea to start thinking about some way of >> storing queries on Wikidata maybe? On one hand, they are just >> strings, >> on the other hand, they are code - like CSS or Javascript - and >> storing >> them just as strings may be inconvenient. Maybe .sparql file >> extension >> handler like we have for .js and .json and so on? >> >> -- >> Stas Malyshev >> smalyshev(a)wikimedia.org <mailto:smalyshev@wikimedia.org> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org >> > >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> <https://lists.wikimedia.org/mailman/listinfo/wikidata> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org >> > >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> <https://lists.wikimedia.org/mailman/listinfo/wikidata> >> >> >> >> >> -- >> ___________________________ >> >> The Timeline of Everything >> >> www.histropedia.com <http://www.histropedia.com/> >> >> Twitter <https://twitter.com/Histropedia> Facebo >> <https://www.facebook.com/Histropedia>ok >> <https://www.facebook.com/Histropedia> Google + >> <https://plus.google.com/u/0/b/104484373317792180682/1044843 >> 73317792180682/posts> >> L <http://www.linkedin.com/company/histropedia-ltd>inke >> <http://www.linkedin.com/company/histropedia-ltd>dIn >> <http://www.linkedin.com/company/histropedia-ltd> >> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> <https://lists.wikimedia.org/mailman/listinfo/wikidata> >> >> >> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> > > _______________________________________________ > Wikidata mailing list > Wikidata(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata >

talk page templates are definitely a valid alternative. The main benefit I see in storing SPARQL query examples via a property of a property is that they'd become discoverable via SPARQL themselves, so for example you could allow users to find interested queries limited to a set of properties with given characteristics (basically allowing filtering on all properties of properties). Might be nice, but we need a good way to present the query in the UI (see Agreed. I imagine, from a design perspective, these "helper" properties (like P1855) that are not really part of the data model could be grouped together and presented via a dedicated UI element, like we do for identifiers. If you could store queries, you could also store queries for each item that I hadn't thought of this use case, but I too see how it might be useful. Are there other good examples of properties that take code snippets as a value?